ipfs://{CID}/{optional path to resource}
其他仅依赖HTTP的工具在以规范形式接见IPFS内容时也会遇到类似的错误,例如Curl 和Wget。
IPFS其他相关工具可以解决这些内容接见错误。然则,并非每个用户都有权更改(或能够更改)他们的计算机设置。IPFS**提供基于HTTP的服务,该服务允许不领会IPFS的浏览器和工具接见IPFS内容。
无论谁部署**以及任何IPFS**在那里分析对任何请求的IPFS内容标识符的接见。因此,为了获得**性能,当需要**服务时,应使用离你最近的**。
#形式
#内陆**
你的计算机可能会将**作为内陆服务托管;例如,在localhost:8080。若是安装了IPFS桌面,则您具有内陆**服务或另一种形式的IPFS节点。
#专用**
运行IPFS桌面或另一种形式的IPFS节点触发与其他IPFS对等方的毗邻实验。
专用网络管理员可以将此类毗邻实验视为潜在的安全破绽。位于专用网络内部并运行受信托代码库的专用IPFS**服务器为对外部托管的IPFS内容举行读/写接见提供了一种替换体系结构。
防火墙后面的**仅代表专用**的一个潜在位置。更一样平常地,当被设置为限制对来自特定域或公共互联网的一部门的请求的接见时,可以将任何**视为专用**。
#公共**
公共**运营商包罗:
协议实验室,用于部署公共**,ipfs官网
第三方公共**。
协议实验室维护公共**列表及其状态。
类
**分类涉及多个方面:读/写支持、分析气概、服务。选择**使用形式具有安全性,性能和其他功效寄义。
#只读和可写**
上文前面的部门中讨论的示例说明晰使用只读HTTP**通过HTTP GET方式从IPFS获取内容的历程。可写HTTP**也支持POST,PUT和DELETE方式。
#分析气概
存在三种分辨率样式:小路、子域名、DNS链接
小路:上面讨论的示例接纳路径分析:
接见网站https {gateway URL}/ipfs/{content ID}/{optional path to resource}
然则,路径分析**违反了同源计谋珍爱一个网站免受欠妥接见另一个网站的会话数据的损害。
子域名:子域分析样式保持了对单一泉源计谋的合规性。规范的接见形式
接见网站https {CID}.ipfs.{gatewayURL}/{optional path to resource}
导致浏览器将每个返回的文件解释为来自差别的泉源。子域分析支持始于Go-IPFS 释放0.5.0。
DNS链接:每当IPFS内的数据内容发生更改时,IPFS都市凭据该数据的内容建立一个新的CID。许多应用程序需要接见文件或网站的新版本,但不知道该新版本的确切CID。行星际名称服务(IPNS)允许版本无关的IPNS标识符分析为当前版本的IPFS CID。
与版本无关的IPNS标识符包罗一个哈希。当**处置花样的请求时
接见网站https {gatewayURL}/ipns/{IPNS identifier}/{optional path}
**将使用IPNS将IPNS标识符分析为当前版本的CID,然后获取响应的内容。然则IPNS标识符可能会以的通常形式引用完全限制的域名example.com。
当**识别出IPNS标识符时,就会发生DNSLink分析example.com。例如,URLhttps://libp2p.io返回该网站的当前版本(存储在IPFS中的网站)
如下所示:
**吸收以下形式的请求:
接见网址https {gateway URL}/ipns/{example.com}/{optional path}
**在请求域的DNS TXT纪录中搜索{example.com}形式为dnslink=/ipfs/{CID}或的字符串_dnslink=/ipfs/{CID}。若是找到,则**使用指定的CID举行服务ipfs://{CID}/{optional path}。与路径分析一样,这种形式的DNSLink分析违反了单一泉源计谋。域运营商可以通过Alias在DNS中添加引用合适IPFS**的纪录来确保单源计谋合规性以及内容的当前版本的交付;例如gateway.ipfs.io。
该Alias纪录将对此的任何接见重定向example.com到指定的**。因此,浏览器接见网址https {example.com}/{optional path to resource}重定向到指定的**的请求Alias。
**接纳DNSLink分析从IPFS返回当前内容版本。浏览器不会将**视为内容的泉源,因此将强制执行单一泉源计谋来珍爱example.com。
**服务
当前,HTTP**可以接见IPFS和IPNS服务
使用类
**接见的**形式取决于目的内容的性子。
任何形式的**都为没有IPFS原生支持的应用程序提供了桥梁。应用内的本机IPFS实行可带来更好的性能和安全性。
何时不使用**
#延迟敏感的应用
任何**都市导致延迟完成所需的操作,由于**充当请求源与IPFS节点或能够返回所需内容的节点之间的中介。若是服务**较早地缓存了所请求的内容(例如,由于先前的请求),则缓存消除了此延迟。
**的过分使用还会由于请求排队而导致延迟。在处置对延迟敏感的历程时,您应该致力于在应用程序中使用本机IPFS节点(最快),或作为内陆服务守护程序(险些一样快)使用。若是失败,请使用安装为内陆服务的**。请注意,当IPFS节点在内陆运行时,它包罗一个**http://127.0.0.1:8080。
所有时间不敏感的历程都可以通过公共/私有**举行路由。
#需要端到端密码验证
由于存在第三方**破绽,因此需要对内容读写举行端到端验证的应用程序应尽可能避开**。若是应用程序必须使用外部**,则此类应用程序应使用ipfs.io或受信托的第三方。
局限性和潜在解决方式
#中心化
**的使用需要基于位置的寻址:
接见网址https {gatewayURL}/ipfs/{CID}/{etc}很容易。**URL可以成为用户标识内容的句柄。也就是说,统一参考定位符(URL)等同于(欠妥)统一参考标识符(URI)。现在,假设由于防火墙而使**离线或无法从其他用户的位置接见**。现在,由该基于**的URL不准确地标识的内容也显得无法接见,从而使IPFS的一项关键优势失去了作用:去中心化。
同样,将DNSLink分析与DNS TXT纪录Alias中的dnslink={value}字符串中所指定的一起使用会强制请求通过域的所选**。若是指定的**过载,脱机或受到威胁,则包罗该内容的所有流量都将被删除,禁用或嫌疑。
#信托
反过来,信托特定的**要求您信托**的发表证书发表机构和该**使用的公钥基础结构的安全性。证书发表机构或公共密钥基础结构的实现可能会损坏**的可信度。
#计谋
为了防止一个网站不准确地接见与另一个网站关联的HTTP会话数据,请使用同源计谋仅允许剧本接见共享公共域名和端口的页面。
思量两个存储在IPFS中的网页:ipfs://{CID A}/{webpage A}和ipfs://{CID B}/{webpage B}。代码onwebpage A不应接见来自的数据webpage B,由于它们不共享相同的内容ID(泉源)。
然则,使用一个**接见两个站点的浏览器可能不会实行该安全计谋。从该浏览器的角度来看,两个网页都有一个配合的泉源:URL中标识的**
接见网址https {gatewayURL}/…。
子域**的使用可以制止违反同源计谋。在这种情形下,**对两个网页的引用变为:这些页面没有相同的泉源。同样,使用DNSLink**可以制止违反同源计谋。该IPFS公共**检查标识那些制止违反同源计谋的公共**。
#跨域资源共享(CORS)
CORS允许网页允许具有差别泉源的页面接见指定的数据。该IPFS公共**检查标识支持CORS的那些公共**。
#**中间人破绽
使用公共或私有HTTP**会牺牲对准确内容的通报的端到端加密验证。思量浏览器使用URL获取内容的情形接见网址https ExampleGateway.com/ipfs/{cid}。受到损坏的用户ExampleGateway.com提供中间人破绽。
包罗:用虚伪内容取代通过CID检索到的现实内容;将查询和响应的副本以及查询浏览器的IP地址转移到第三方。
遭到损坏的可写**可能会将伪造的内容注入IPFS网络,并返回用户以为是真实内容的CID。
例如:
爱丽丝将的余额123.54发送到已损坏的可写**。
**当前存储的余额为0.00,因此它将伪造内容的CID返回给Alice。
爱丽丝将伪造的内容CID提供给鲍勃。
Bob使用此CID获取内容,并通过密码验证了的余额0.00。
为领会决这种部门风险,公用**cf-ipfs.com用作具有相同泉源计谋和CORS支持的自力,受信托的参考。
#下载文件时假定的文件名
下载文件时,浏览器通常会通过查看路径的**一部门来预测文件的文件名。例如:
接见网址https {domainName/tld}/{path}/userManual.pdf下载名称为内陆存储的文件userManual.pdf。不幸的是,当直接链接到IPFS中没有包罗目录的文件时,CID成为最终组件。将文件名设置为CID的下载文件存储为人性化设计测试失败。
要变通解决此问题,您可以?filename={filename.ext}在查询字符串中添加一个参数,以争先指定内陆存储的下载文件的名称:
#缓存
**可能会缓存来自DNS TXT纪录的DNSLink,默以为一小时。内容更改后,缓存的DNSLink继续引用现在已过时的CID。为了限制过时的缓存内容的通报,域操作员应将DNS纪录的生计时间参数更改分钟为60。
文章标题:深度理解IPFS网关
文章链接:https://www.btchangqing.cn/198956.html
更新时间:2021年02月24日
本站大部分内容均收集于网络,若内容若侵犯到您的权益,请联系我们,我们将第一时间处理。