Constant or well known mox-extension://<uuid> for webExtension?

Add-ons
#1

I’m developing a firefox add-on and would like to embed a redirection page into my extension. This redirection page needs to be whitelisted. Is there a way to know what the moz-extension:// will be at development time? The GUID seems to change for each install of the add-on. When installing from the developer add-on page I get one GUID, but after I have published and signed the add-on I get another GUID. Will this GUID change from machine to machine and user to user?

developer add-on install
moz-extension://a270a64d-706e-0b40-ba5f-e7e1521c5caf/redirect.html

signed add-on install
moz-extension://da6cb425-9b55-0a44-bab9-f07af26d20f8/redirect.html

For Google Chrome add-ons once an add-on has been published to the store that GUID remains constant for the each install and updates to the extension.

#2

These IDs currently are unique per installation of an extension, but there is a discussion about this happening over at https://bugzilla.mozilla.org/show_bug.cgi?id=1271663

#3

Hi,

Why don’t you use self.data.url from the background script to get the URL of the local resource?
I didn’t try, but if you don’t have a local resource, maybe you can use self.data.url with a data-url?

Emmanuel

#4

@emmanuel_sellier self.data.url appears to be available only in the add-on SDK. My question is for a WebExtensions based package.

#5

How about this? (Untested)

browser.extension.getURL ('./')
#6

"
Return value

string. The fully-qualified URL to the resource.
"

The fully-qualified URL to the resource will still be unique to the specific install of the extension. Because the URL is unique to the install it cannot be used to register a whitelisted domain with an external service.

What is needed here is an identifier which is well known for all installs of the extension. If personA and personB both install the extension they should both get the same mox-extesion://

#7

That’s by design.

You can do whatever you want with the dynamic identifier obtained this way, can’t you?? Just different from Chrome. (Different is good, because Chrome is terrible for privacy.) Tell the external service the identifier each time, but this doesn’t seem good for privacy. You need to be clear in your add-on’s privacy policy about its behavior.

The identifiers need to be different for each installation in order to make privacy-invading fingerprinting harder. But this should be done to improve the situation:
https://discourse.mozilla-community.org/t/proposal-isolated-content-environment/9866?u=desktopd

#8

Yes inside the extension you can do whatever you want with the dynamic identifier, unfortunately the issue isn’t using the URI inside of the extension. This design makes it impossible to whitelist an authentication callback url inside the extension. The callback url would necessarily need to be hosted somewhere outside of the extension, with a well know address to be added to a whitelist.

This limitation is being discussed in the following bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1271663
https://bugzilla.mozilla.org/show_bug.cgi?id=1257989

#9

Yes, you would need an external resource that you know will never be valid for example and then just interecept that. Nothing stops you from using localhost.myextensionname as callback point, for example. You can get navigation requests and read the parameters you get that way. Some services even have localhsost whitelisted as default callback target, as in other environments you don’t have any fixed URI to go to either.

1 Like
#10

@freaktechnik, I don’t think I understand your suggestion. In a production environment on a customers machine how exactly will localhost.myextesionname be available as the base for a callback url?.

I hope that you aren’t suggesting we ask our customers to run a local http server. A link to documentation for your suggestion would be very helpful.

#11

First off, I made a little mistake, rather than doing localhost.myextensionname it would probably be better to do myextensionname.localhost, as there will never be domains registered with .localhost as TLD.

Now to the how to do it: before you open your tab for your user to authenticate with the 3rd party, you’d attach a webNavigation listener for onBeforeNavigate or maybe onComitted (I haven’t played around with them). I think at least parts of the filters were implemented for Firefox 50, but in any case you’d wait until you’d get the callback URL you specified (for example localhost) with the parameters set you need (or the error parameters set) and maybe check that’s in the correct tab and then you’d redirect back to your own page within the extension (presumably using tabs.update).

#12

Two additions:
You might not need webRequest, maybe tabs.onUpdate is sufficient - I am not very comfortable with the WebExtensions APIs yet.

Further this flow was already required for any callback that had to be an http or https URL, as extensions always had their own protocols.