I am trying to update an old Firefox add-on that was based on XUL & XPCOM and re-implement it in a WebExtention. This new add-on will use a firefox sync server 1.1 to exchange some info securely, based on this. I cannot use firefox sync server 1.5 as this doesn't use J-PAKE. I have been able to talk to the server fine, but now stumbling on the second step of the protocol.
Mobile/Desktop generates PIN from random weak secret (4 characters a-z0-9) and
the channel ID, computes and uploads J-PAKE msg 1. New for v2: To
prevent double uploads in case of retries, the If-None-Match: * header
is specified. This makes sure that the message is only uploaded if the
channel is empty. If it is not then the request will fail with a 412
Precondition Failed which should be considered the same as 200 OK. The
412 will also contain the Etag of the data was the client just
uploaded.
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: }
The problem is the old implementation used XPCOM objects:
var jpake = Component.Classes["#mozilla.org/services-crypto/sync-jpake;1"].createInstance(Ci.nsISyncJPAKE);
and allows to use the function described here and implemented here
jpake.round1(singerId, gx1, gv1, r1, gx2, gv2, r2)
which took care of generating: gx1, gv1, r1, gx2, gv2 and r2.
Is there a way to use the XPCOM objects in WebExtentions? Or am I forced to use Add-on SDK, with XPCOM low-level API?
I have tried to use curve25519.js to emulate the values from here, but with no success.
Any help is welcome,
Thanks
This is the email that was sent on the dev channel where you can use a WebExt forom inside a classic addon, it meant for transition purposes, I'm not sure of how permanent it is:
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.
Related
Trying to find information on how to implement deferred deep linking in electron app but can't find it in the official electron documentation.
We have an electronic application. I need the following behavior: when a user tries to open a link of this type -> custom-protocol: // some-data in the browser, if the application is not installed, then automatically download the application and, after installation, pass the parameters contained in the link (some-data) to the application. Can anyone suggest how to implement this in electronic or a link to the documentation or show some abstract example of implementation
On Windows, custom protocols are stored in the registry. This is a chicken and egg problem because your application already has to be installed on the system for the registry entry to exist.
If you rewrite your application as a UWP app (lol) you might be able to check with getInstalledRelatedApps to see if the app is already installed.
If you want to streamline how your application is installed from the web, consider using ClickOnce.
So basically you just want a way to pass some query params to your application when installed from your website.
You can do this if you package your electron application as an MSIX. Check out the article below from Microsoft, that documents the process:
Passing query params to an MSIX packaged app
I am trying to integrate Google Tag Manager into an Electron app,
but it doesn't seem to be working. it seems like gtm codes I planted in the app are NOT sending the analytics data anywhere.
I found this issue on Electron github repo. Seems like some people are having the same issue.
I wonder if it's impossible at all to integrate GTM on Electron, or is there any way around to do this?
[Update]
While reading Alexander Leithner's answer, a further question popped up.
on Google Tag Manager - Dev Guide - Security, it says:
While most of the tag templates in Google Tag Manager are also
protocol relative, it's important to make sure that, when setting up
custom tags to fire on secure pages, those tags are also either
protocol relative or secure.
Does file:// protocol matters because GTM is protocol relative? Wouldn't it be possible to bypass this with GA's forceSSL=true option which can be set on GTM Interface?
[Final Update]
I found the perfect answer in this blog post:
Run Google Tag Manager And Google Analytics In Local Files.
Thank you Eike Pierstorff, for giving me the hint of setting storage to none, it led me to this post.
GTM by default used to use the same protocol as the webpage - that's what "protocol relative" means. I.e. there is a bit of code that loads the GTM library, and if this uses the file protocol (as per the embedded wegpage) it will try to load the library as a file, which does not work. However GTM has switched from protocol relative to https by default, so I don't think GTM is your problem here.
You mention Analytics data, and if this refers to Google Analytics then your problem is not with GTM, it is that GA does not work on local files. Google Analytics uses a cookie to store the clientId (which is needed to aggregate individual hits into sessions/users), and since you cannot set cookies on a local file this does not work.
A possible workaround would be to go to your GA tag in GTM, to the "set fields" settings, set "storage" to "none" (which means that no cookie is set) and pass in a clientId manually.
As this comment by Samuel Attard (MarshallOfSound), who is an Electron developer, states that Google Tag Manager does not work when the including webpage is loaded using a file:// URL.
If you'd instead load your application via http:// (or more preferably via https://), you would be able to use Google Tag Manager.
I created a simple mozilla addon. Debugging is fine - all works. Now I want to install it and have problems. I know Im supposed to create install.rdf, but cant do this. I need it as minimum as possible - addon will work only on 4 PC's at the office.
My files:
/icons
- background.js
- manifest.json
Can You help?
The publishing process for firefox addons varies depending on whether you want the extension to be public, unlisted, etc.
It sounds to me like you want a private extension with no web store distribution. To do this, you will need to create a web store account and get the extension signed.
Read this about getting the extension signed:
https://developer.mozilla.org/en-US/Add-ons/Distribution
That process will result in a signed extension that you can then privately distribute however you choose.
Packaging is detailed at
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Publishing_your_WebExtension#2._Create_an_account_on_addons.mozilla.org
Embedded WebExtensions talks all about how to "... embed a WebExtension in a classic bootstrapped extension or an Add-on SDK add-on."
But I've got neither a "bootstrapped" nor "Add-on SDK" extension, just a decade old plain old XPCOM/overlay extension. I don't have a bootstrap.js to have a startup, nor do I use the Add-on SDK for whatever it does.
I tried adding
<em:bootstrap>true</em:bootstrap>
But all that accomplishes is completely destroying the extension, it only loads that (empty) new bootstrap.js file.
Indeed, I want to migrate: The data that my classic extension has needs to be exported to the webext version, for good user experience.
At our tracking bug a user has posted a helpful link:
https://github.com/mdn/webextensions-examples/tree/master/embedded-webextension-overlay
Which boils down to
const {
LegacyExtensionsUtils,
} = Components.utils.import("resource://gre/modules/LegacyExtensionsUtils.jsm");
const myOverlayEmbeddedWebExtension = LegacyExtensionsUtils.getEmbeddedExtensionFor({
id: addonId, resourceURI: baseURI,
});
myOverlayEmbeddedWebExtension.startup().then(({browser}) => {
dump(`${addonId} - embedded webext started\n`);
browser.runtime.onMessage.addListener(msg => {
dump(`${addonId} - received message from embedded webext ${msg}\n`);
});
}).catch(err => {
Components.utils.reportError(
`${addonId} - embedded webext startup failed: ${err.message} ${err.stack}\n`
);
});
Which is surely the equivalent of what the bootstrap/SDK code is doing for you.
You can only rewrite it from scratch using the WebExtension APIs.
Note that the WebExtensions model requires you only use the APIs explicitly exported for use by extensions, so prepare to drop some features during the rewrite, or even to find that it's impossible to reimplement the extension altogether (unless you convince Mozilla to implement the new APIs you need or implement it yourself in a WebExtension Experiment -- still limited to Nightly/Dev.edition).
See Porting a legacy Firefox extension
[edit] the "embedded WebExtension" does indeed require your "outer" extension to be bootstrapped or Add-on SDK-based (so no "classic" extensions), but it was only intended to be used for gradual migration and will not work in Firefox 57.
One option that I suggest to the people in similar situations, is to provide an Export function in the current legacy addon and an Import in the WebExtension version. While it is not an automatic migration (has to be user action), it overcomes some of the limitations of the WebExtension local-file access.
Using the Export, users will be prompted to save their complete data to hard-disk.
Then the next upgrade which would be a WebExtension, prompts the users to Import the saved data.
I have a question about my ActiveX control not always working in IE on other machines.
Context: I'm working on an internal app for my company. It is designed to be a standalone web-page config tool for viewing a static customized version of our web app. The user may select the colors, images, and other settings they would like to see, and these will be present in the static mockup/preview version on their machine when they click a button.
Implementation: my javascript file creates a filesystem/activex object that essentially creates a temporary javascript file to which a list of values are written. Then when the user previews the configuration, the javascript file is located and values are loaded dynamically into the dom, etc etc. Naturally this functionality only works in Internet Explorer and is shady at best, but is my only way of implementing a purely zero configuration, client-side dynamic webapp.
Problem: When I test out my script, Internet Explorer prompts me twice about ActiveX controls and I say "yes" to them and the ActiveX functions work. I do this every single time I open my page. But sometimes when I send the file to another person so they can use it, they don't get the notifications so it doesn't work. However sometimes they do get notifications and it does work! I am using default security settings for IE so there should be no difference between my settings and theirs.
Could this be related to my user permissions vs theirs, or the fact that the files are read-only (because they are coming from source control and are also being made read-only when put on the shared drive.) or unknown dark Microsoft forces beyond human comprehension?
Thanks,
Josh
I believe you may want to create an HTA (HTML Application) instead of a web page. Writing HTA's gives you more privileges as far as ActiveX objects are concerned. Check out this page from Microsoft: http://msdn.microsoft.com/en-us/library/ms536496(v=vs.85).aspx.
To answer your question about privileges, I believe that some of your coworkers' IE settings probably prevent web pages from using ActiveX objects. Your settings may be such that you are prompted whenever ActiveX object are about to be created.