1

我正在尝试更新基于 XUL 和 XPCOM 的旧 Firefox 插件并在 WebExtention 中重新实现它。这个新的附加组件将使用firefox 同步服务器 1.1安全地交换一些信息，基于此。我不能使用 firefox 同步服务器 1.5，因为它不使用 J-PAKE。我已经能够很好地与服务器交谈，但现在在协议的第二步上绊倒了。

移动/桌面从随机弱密钥（4 个字符 a-z0-9）和频道 ID 生成 PIN，计算并上传 J-PAKE msg 1. v2 的新功能：为了防止重试时重复上传，If-None-匹配： * 标头已指定。这样可以确保仅在通道为空时才上​​传消息。如果不是，则请求将失败，并显示 412 Precondition Failed，这应该被视为与 200 OK 相同。412 还将包含客户端刚刚上传的数据的 Etag。

C: PUT /a7id HTTP/1.1
C: If-None-Match: *
C: 
C: {
C:    'type': 'receiver1',
C:    'payload': {
C:       'gx1': '45...9b',
C:       'zkp_x1': {
C:          'b': '09e22607ead737150b1a6e528d0c589cb6faa54a',
C:          'gr': '58...7a'
C:          'id': 'receiver',
C:       }
C:       'gx2': 'be...93',
C:       'zkp_x2': {
C:          'b': '222069aabbc777dc988abcc56547cd944f056b4c',
C:          'gr': '5c...23'
C:          'id': 'receiver',
C:       }
C:    }
C: }

问题是旧实现使用了 XPCOM 对象：

var jpake = Component.Classes["@mozilla.org/services-crypto/sync-jpake;1"].createInstance(Ci.nsISyncJPAKE);

并允许使用此处描述并在此处实现的功能

jpake.round1(singerId, gx1, gv1, r1, gx2, gv2, r2)

负责生成：gx1, gv1, r1, gx2, gv2 and r2.

有没有办法在WebExtentions中使用 XPCOM 对象？还是我被迫使用带有XPCOM 低级 API 的Add-on SDK？

我曾尝试使用curve25519.js来模拟此处的值，但没有成功。

欢迎任何帮助，谢谢

4

1 回答 1

0

这是在开发频道上发送的电子邮件，您可以在其中使用经典插件中的 WebExt 论坛，它用于过渡目的，我不确定它的永久性：

Hi all,
As part of the ongoing changes to the WebExtensions internals, we are working to enable any restartless classic extension (restartless add-ons  based on a bootstrap.js file and add-ons created using the SDK) to embed a WebExtension inside them,
as a path for gradually porting existent addons into a WebExtension and gradually move into the embedded WebExtension any features that has better support as WebExtensions APIs.

The related bugzilla issues are:
- "Bug 1252227: Embed WebExtension in Classic Extensions"
- "Bug 1252215: Expose WebExtension messaging to Classic Extensions"
- "Bug 1269342: XPIProvider should provide optional embedded webextension instance to classic extensions"
- "Bug 1269347 - Expose the optional embedded webextension as a builtin SDK module"

Any classic extension that is going to use this feature will have, besides the classic extension code which is running with "browser" privileges, an embedded webextension running inside it (with the same addon id of the container addon) and the classic extension code will be able to exchange messages with any of the available embedded webextension contexts
(e.g. a background page, a popup page or a content script) using a subset of the WebExtension `runtime` API (in particular it will be able to subscribe listeners to `onMessage` and `onConnect`).

All the embedded webextension resources will be loaded from the `webextension/` sub directory of the container add-on resources (and the embedded webextension will not be able to load anything from outside that directory, 'cause it is going to be its base URI).

As you can imagine (many thanks to Andrew for pointing it out during our brief planning chats), this new feature is probably going to need some sort of special handling by both AMO and the addons linter, and I'm starting this email thread to collect more feedback and ideas.

Some initial thoughts about the `addons linter`:

- the addons linter should be able to recognize hybrid addons and do not confuse hybrid addons for a pure webextension addon
  (e.g. the hybrid addons will have potentially more privileges that the ones listed in the webextension manifest file)

- the addons linter should check that there are no conflicts betwen the metadata in the install.rdf/package.json and the metadata in the `webextension/manifest.json` file.

- the linting of the webextension part can probably ignore the file which are not in the `webextension/` subdir, because the webextension will not being able to load anything from outside that directory

- the linting of the classic extension part needs to lint all the files in the addon (because the resources in the `webextension/` can be accessed from the classic extension part of the addon)

- the linting of the classic extension part should warn the reviewer on any suspicious usage of files manipulation? (can the classic extension part potentially change the packages resources? e.g. the manifest file or a background script, loaded in the embedded webextension and trick the linter)

Some initial thoughts about `AMO`:

- the hybrid addons submission on AMO should be supported, e.g. for signing or listing (probably not a lot of changes are needed, it should be recognized as a classic extension addon and the addon metadata retrieved from the install.rdf file)

- during the add-onreview, should AMO highlight when an addon is an hybrid add-on?

Any further thoughts, feedback or ideas are absolutely welcome.
于 2016-05-24T23:39:30.270 回答