1380739 - Show a message in the Browser Console when webRequest API doesn't give access to a request

Status: RESOLVED WONTFIX

(WebExtensions :: Request Handling, defect, P5)

Description

[tumpio]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170630112252



Actual results:

The webRequest API accepts the webRequest.BlockingResponse silently but the action of it may be ignored for some "sensitive" requests unknown to the user of the API.


Expected results:

The API should throw an exception when returning a webRequest.BlockingResponse for requests which it doesn't grant access to.

Comment 1

[tumpio]

Attachment: Test case for the bug

Added a test case webextension that redirects a request which webRequest API does not grant access to.

Steps:
1. Load it as temporary add-on.
2. Visit : https://addons.mozilla.org/en-US/thunderbird/

Actual results:
Following message is printed to browser console:

"Redirecting to https://addons.mozilla.org/en-US/thunderbird/extensions/?sort=updated" 1 background.js:6:5

but the request is not redirected.


Expected results:
Throw an exception for ungranted request.

Comment 2

[Andrew Swan [:aswan]]

When exactly do you expect an exception to be thrown?  A blocking webRequest handler requests changes by returning a value from an event listener at which point the flow of control has left the extension and does not return until some other unrelated event or callback occurs.

Comment 3

[tumpio]

I think it would need to be thrown on request listener registration for ungranted listener or so. Even a message in browser console would have notified me of this behaviour of webRequest API.

I tried to debug my extension until I released what actually was the reason for this behaviour. I have also opened a bug to document these unprivileged requests. In addition, my extensions is requesting permission for <all_urls> as such I expected it to work on all urls.

Comment 4

[tumpio]

I'm not familiar how permission management works in webextensions. Can the extension detect if it has insufficient permissions regarding the usage of an API? Maybe some permission exception should fire which extensions can listen to.

Comment 5

[Andrew Swan [:aswan]]

(In reply to tumpio from comment #3)
> I think it would need to be thrown on request listener registration for
> ungranted listener or so.

Even if that were feasible to implement, what about a listener that is broad enough that it covers some restricted urls and other unrestricted urls?  (e.g. <all_urls> is a trivial example)

> Even a message in browser console would have
> notified me of this behaviour of webRequest API.

We have bug 1309033 for that.  I'm inclinced to close this bug in favor of that one.

Comment 6

[tumpio]

> We have bug 1309033 for that.  I'm inclinced to close this bug in favor of
> that one.

If it covers the webRequest API and not only content scripts, yes I think this bug can be closed.

Comment 7

[Andrew Swan [:aswan]]

Oh sorry you're right.  Adjusting the title of this one to cover webRequest.

Comment 8

[Shane Caraveo (:mixedpuppy)]

I'm against adding the exception or console output for webrequests (because that may mean all requests), use the network console in the browser tools if you need to see unhandled requests.  The primary issue here is access to the small set of restricted urls (which AMO is one).  Either of the bugs under "also see" would provide a work around (bug 1334918 or bug 1380729), so closing this.

Comment 9

[tumpio]

I understand, thanks for your time Shane and Andrew!