1416146 - redirect from https(s) to extension URL is broken

Status: RESOLVED WONTFIX

(WebExtensions :: Request Handling, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

I'm helping a Chrome extension migrate, and they reported this as not working.

I'm waiting for more info, but sounds like it's here:

https://github.com/blockadeio/firefox_extension/blob/master/extension/resources/js/core/background.js#L90

Will make a reduced testcase and test out locally.

Comment 1

[Dietrich Ayala (:dietrich)]

No notes in the docs specifically about redirects to extension URLs.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/BlockingResponse

However, there is a note about non-HTTP schemes generally, pointing to bug 707624, which is about lack of e10s support for redirecting to data URIs.

I asked there about whether that applies in this case also.

Comment 2

[Dietrich Ayala (:dietrich)]

Hi Andy! Is this a known issue? Can we bump priority as it's a Chrome compat problem preventing functional migrations?

Comment 3

[Andy McKay]

This is probably a bit of a stretch but bug 1149250 might help here. Other than that, sorry this isn't likely to be on our radar soon.

Comment 4

[Dietrich Ayala (:dietrich)]

I dug into this, and it seems this is actually supposed to work, was implemented by Shane in bug 1416146.

See Honza's comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=707624#c11.

Comment 5

[Kris Maglione [:kmag]]

It's not possible to redirect a request to an extension resource that isn't listed in its manifest's "web_accessible_resources" section.

Comment 6

[Dietrich Ayala (:dietrich)]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #5)
> It's not possible to redirect a request to an extension resource that isn't
> listed in its manifest's "web_accessible_resources" section.

Can you clarify? The extension needs to list the moz-ext URL in the manifest? Can you link the docs for it?

Is this different from Chrome's implementation?

Comment 7

[Dietrich Ayala (:dietrich)]

The way they have it works fine for Chrome, so re-opening until we can confirm what exactly our different behavior is, and why. And whether or not we need a new bug for parity.

Comment 8

[Shane Caraveo (:mixedpuppy)]

Chrome may not (per comment 7) require a web accessible resource when an extension redirects to itself.  For Firefox, the security context of the loading document wont allow for a redirect from a public url to a web-ext url without the web-ext url being listed in the manifest.  The check happens here:

https://searchfox.org/mozilla-central/source/netwerk/protocol/res/ExtensionProtocolHandler.cpp#369

If we wanted to change this, we'd probably have to do some changes in nsHttpChannel to have a way to create internal redirects, but I haven't really thought it through.  

Using web_accessible_resources would work for both Chrome and Firefox.

Comment 9

[Shane Caraveo (:mixedpuppy)]

I don't think this is a regression as much as it is a minor incompatibility that has a compatible solution.  We should document it under both WebRequest[1] and web_accessible_resources.  Something along the lines of "If an extension wants to redirect a public url to an extension url, the extension url must be listed in the manifest under 'web_accessible_resources'".

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest

Comment 10

[Shane Caraveo (:mixedpuppy)]

closing, dev-doc will pick up later.

Comment 11

[Dietrich Ayala (:dietrich)]

Ok, great - thanks very much for clarifying what's happening here Shane, and why it's not working for people porting their extensions to Firefox.

If there's a guide for porting Chrome extensions to Firefox, should also be documented there.

If there's not a security reason why the behavior is different, then should I open a new bug for supporting this functionality? I'm not sure what possible upside there is for needlessly making it harder for Chrome extensions to work seamlessly in Firefox.

Comment 12

[Shane Caraveo (:mixedpuppy)]

I don't feel like its necessary since there is a compatible work around, but I'd personally be fine allowing an extension to redirect to its own urls without the url listing in the manifest.  I've a feeling fixing this is not trivial.  I don't recall any method by which we track where and how a redirect is created, so we'd have no way to tie back to the responsible party when we do the security checks.  You might ping mayhemer and see if he thinks this is simple or not.

Comment 13

[Will Bamberg [:wbamberg]]

I've scattered a few reference to this:

* https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities#webRequest

* https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest#Chrome_incompatibilities (included from the "Chrome incompatibilities" page)

* https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest

* https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/BlockingResponse

* https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources

...let me know if this covers it.

Comment 14

[Shane Caraveo (:mixedpuppy)]

(In reply to Will Bamberg [:wbamberg] from comment #13)
> I've scattered a few reference to this:
> 
> *
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/
> Chrome_incompatibilities#webRequest

It should also be noted that any website may then link/redirect/etc to that url, and extensions should handle external input in a secure manor.

> *
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/
> web_accessible_resources

I think this page should probably have some kind of section on security implications of having a web_accessible_resources page.  Basically any accessible resource needs to treat any get/post/etc data as it would from any untrusted source, as if it were a page on  a webserver somewhere.

Comment 15

[Tomislav Jovanovic :zombie]

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/BlockingResponse