我正在将基于 SDK 的 Firefox 扩展转换为 WebExtensions，并且遇到了更新扩展的问题。当前的扩展程序以及 update.rdf 文件托管在我自己的域(这是一个 HTTP 域)上。
现在，对于基于 SDK 的附加组件，只要使用 McCoy 签署更新 list ，就可以通过 HTTP 进行更新。工具和更新文件的有效哈希值已在 list 中提供。除此之外，install.rdf 将保存用于签署 update.rdf 的 key 的公钥部分。
似乎没有选项可以使用网络扩展来执行此操作(没有公钥的 list 条目，也没有签名的更新 list (.json) 条目)。
这是否意味着 Firefox 将只允许自托管扩展通过 HTTPS 进行更新？这将如何影响当前托管在 HTTP 域上的基于 SDK 的扩展？他们能够接收(至少一个)更新吗？
最佳答案
正如您似乎已经确定的那样，基于 WebExtensions 的附加组件的 update.rdf 必须通过 HTTPS(而不是 HTTP)提供服务。 update.rdf 文件的 URL 必须是 HTTPS。 documentation for the update_url property in the manifest.json applications key在这一点上是明确的:
update_urlis a link to an add-on update manifest. Note that the link must begin with "https". This key is for managing extension updates yourself (i.e. not through AMO).
无法使用其他类型的附加组件可用的替代安全方法来提供 updateKey (并签署update.rdf)在 install.rdf 中扩展名中包含的文件。
基于附加 SDK 的扩展以及其他类型的非 WebExtensions 附加组件将继续能够以与以往相同的方式通过 HTTP 接收其 update.rdf 。
如果您的问题是将附加组件从基于附加 SDK 的附加组件转换为基于 WebExtensions 的附加组件，那么您将需要对该扩展进行更新，以更改更新的 URL已送达。这可以是在转换到 WebExtensions 之前的某个版本中，也可以是在同一时间。无论哪种方式，它都只是附加组件的新版本(通过 HTTP 提供的 update.rdf 表示并进行了适当的签名)。该新版本将具有 update_url (WebExtensions)或 updateURL (所有其他类型)其中 URL 使用 HTTPS 方案。所有后续 update.rdf 文件将通过 HTTPS 提供。
关于firefox-addon - 通过 HTTP 更新自托管扩展，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42719321/