Open Gaubee opened 8 months ago
现在 file 协议是由 file.std.dweb 这个模块提供核心服务,其它模块还能通过适配器的方式额外进行适配,从而来影响一个设备中所有模块对于file:///的内容访问。
file:///
这其实会带来很多困惑,因此这里我提出一些基本理念来避免一些根本性的安全问题发生。
PS: 以下内容中 “file” 指 “file 模块”,“模块” 指 “其它模块”
file://file.std.dweb
正如http://是file://http.std.dweb/fetch的缩写、ws://是file://http.std.dweb/websocket的缩写
http://
file://http.std.dweb/fetch
ws://
file://http.std.dweb/websocket
这也是目前 file 模块提供服务的方式,即便是同一个硬件设备上,模块是不能直接访问到其它模块的文件,但是我们现在通过 picker+realPath 这两接口来实现了直接访问。这其实是一个错误的设计,它打破的原则,是一种妥协,它应该被逐渐废弃。
如果要做所谓的共享,那么概念上不可以脱离我们的“统一传输层”,并且共享必须是“模块与模块”之间发生,而不能是“模块与 file 与模块”的关系,之所以要遵守这种关系,更 DwebBrowser 的愿景有很大关系,我当然不希望基于之前错误设计写出来的代码在未来标准往前走的时候才发现原来的代码都用不了,因此需要及时作出纠正:
就是转发
只转发头,内容还是直连获取
file 发送了两次内容数据,这种场景是 A 需要读取数据,但对于给 B 的数据并不修改,所以可以由 file 直接发出两次数据
但是如果对于每个模块承担资源访问的编程负担,那么这可能会增加模块访问者的心智负担,因为本来是直接面向 file 来做开发的,现在 file 是对方模块私有的东西,导致现在需要换成向对方模块发送数据,让对方模块自己去做 file 的读写,这会非常冗长。因此我们需要一种标准化的方案来解决这个问题:
首先对于服务模块(a.server.dweb)来说,它要提供 file 访问:
class AServer extends MicroModule { override async bootstrap(bootstrapContext) { /// 注册子协议 this.protocol("file.std.dweb", async (protocolContext) => { // 在收到访问的时候 protocolContext.onConnect((clientIpc, reason) => { // 自己连接到 file,构建出一个 子连接 const fileSubIpc = this.connect("file.std.dweb").fork(reason); /// 简单的双向绑定 clientIpc.pipe(fileSubIpc); // 等价于 clientIpc.onMessage((msg)=>otherIpc.send(msg)) fileSubIpc.pipe(clientIpc); /// 也可以在双向绑定是做一些拦截,从而做一些自定义 clientIpc.pipe(fileSubIpc, { onRequest(request, toClientIpc) { if (request.pathname === "/some-custom") { // ... } else { return toClientIpc.request(request); } }, }); }); }); } }
那么对于访问模块(b.client.dweb),它可以这样做使用 sub-protcol 来进行资源访问:
const serverIpc = await dns.connect("a.server.dweb"); await serverIpc.request("file://file.std.dweb/info.txt").text(); // 可以缩写成 file:///info.txt
现在 file 协议是由 file.std.dweb 这个模块提供核心服务,其它模块还能通过适配器的方式额外进行适配,从而来影响一个设备中所有模块对于
file:///
的内容访问。这其实会带来很多困惑,因此这里我提出一些基本理念来避免一些根本性的安全问题发生。
file:///
是file://file.std.dweb
的缩写。如果要做所谓的共享,那么概念上不可以脱离我们的“统一传输层”,并且共享必须是“模块与模块”之间发生,而不能是“模块与 file 与模块”的关系,之所以要遵守这种关系,更 DwebBrowser 的愿景有很大关系,我当然不希望基于之前错误设计写出来的代码在未来标准往前走的时候才发现原来的代码都用不了,因此需要及时作出纠正:
但是如果对于每个模块承担资源访问的编程负担,那么这可能会增加模块访问者的心智负担,因为本来是直接面向 file 来做开发的,现在 file 是对方模块私有的东西,导致现在需要换成向对方模块发送数据,让对方模块自己去做 file 的读写,这会非常冗长。因此我们需要一种标准化的方案来解决这个问题:
首先对于服务模块(a.server.dweb)来说,它要提供 file 访问:
那么对于访问模块(b.client.dweb),它可以这样做使用 sub-protcol 来进行资源访问: