MV3 onAuthRequired is not triggered by requests within service worker

1,007 views
Skip to first unread message

blackout

unread,
Nov 21, 2022, 8:18:50 AM11/21/22
to Chromium Extensions
Hi,
We are managing a proxy extension which searches for a working proxy server before setting it to work on every request on the browser. On mv2 we were doing this on background page. Now with mv3 we need to test proxy server in the service worker. After 2 years of waiting for this bug https://bugs.chromium.org/p/chromium/issues/detail?id=1135492 to be fixed now we encounter the issue that requests made within service worker do not trigger onAuthRequired event.

What happens: Request made with fetch api within service worker is canceled with 407 response.
What do we expect: Request made with fetch api within server worker should trigger onAuthRequired so that we can provide Proxy-Authorization and request succeeds.

What i have tried is that sending the Authorization header with the initial request, before the server even asks for it. But Fetch api still throws error and the request will just be canceled with 407 response.

I am already aware that there is bug report on this issue:

My question is: Is there any workaround for this, where a request made within service worker will trigger onAuthRequired event or sending authorization with the initial request before the server even ask for it.

Thanks

wOxxOm

unread,
Nov 21, 2022, 9:42:26 AM11/21/22
to Chromium Extensions, blackout
The last comment in the bug report says the fix is in Chrome 108 - are you using it?

blackout

unread,
Nov 21, 2022, 9:56:27 AM11/21/22
to Chromium Extensions, wOxxOm, blackout
Thanks for quick response.

Yes, i have tested on Chrome Dev 109.0.5414.10.

What i just have realized is that onAuthRequired is NOT even triggered when request is made from popup page or any content page of the extension. I though it was only the service worker but any requests made from extension pages DO NOT trigger onAuthRequired. I might need to file a bug for this with steps to reproduce the problem.

If i request same URL from a new tab manually, onAuthRequired is triggered on MV3. 

So i am assuming my setup is correct but requests made by the extension are not triggering onAuthRequired. Instead request is canceled with 407 error. (Please see screenshot)

Any ideas for workaround or way to get this fixed asap?
Screenshot 2022-11-21 at 15.52.39.png

wOxxOm

unread,
Nov 21, 2022, 1:50:01 PM11/21/22
to Chromium Extensions, blackout, wOxxOm
See if it works in Chrome Canary for requests made inside a `chrome.offscreen` document, see https://crbug.com/1339382

Oliver Marsh

unread,
Nov 22, 2022, 11:22:21 AM11/22/22
to Chromium Extensions, wOxxOm, blackout
I have been experiencing the same issue, any updates about a possible fix?

blackout

unread,
Nov 23, 2022, 5:31:55 AM11/23/22
to Chromium Extensions, oliver.m...@gmail.com, wOxxOm, blackout
Thank you w0xx0m! Really appreciate the hint for this new api. Following w0xx0m suggestion i could find a workaround which seems to work. 
If you really need your requests from extension pages to trigger onAuthRequired you can create a offscreen document which creates a Web Worker which makes the request for you. It seems like requests made by Web Worker will trigger onAuthRequired. So you can make this work by redirecting all you extension page requests to the worker via messaging.
You could also use popup page or a content page to create Web Worker. This works also but if you want the request in "the background". The offscreen api seems to be workaround until this issue is fixed.

service worker ==> creates == > offscreen ==>  creates ==> Web Worker 
service worker ===> send request(url) message to offscreen ===> sends request(url) message to Web Worker ==> Web Worker makes request (which triggers onAuthRequired in service worker) and sends response back to service worker.

- Doing the request directly in the offscreen page will result in the same issue that onAuthRequired will not be triggered. You need to create a Web Worker in the offscreen page.
- Creating Web Worker in service worker directly does also NOT work. So offscreen api is needed to make this work in the background.

This workaround also requires an extra permission in the manifest: "offscreen". Which will probably deactivate your extension if you update your already existing extension on CWS.

Currently two bug reports are open regarding this issue:

I really hope that these are fixed before January 2023 so we don't need to rely on workarounds which create unnecessary load to the browser. 

wOxxOm

unread,
Nov 23, 2022, 6:12:11 AM11/23/22
to Chromium Extensions, blackout, oliver.m...@gmail.com, wOxxOm
>  [...] permission in the manifest: "offscreen" [...] will probably deactivate your extension if you update your already existing extension on CWS.

No, currently it won't because it doesn't have a warning message of its own.

blackout

unread,
Nov 24, 2022, 5:38:46 AM11/24/22
to Chromium Extensions, wOxxOm, blackout, oliver.m...@gmail.com
Thanks for clarifying. Does the same apply for the new permission "webRequestAuthProvider"? We have an active extension with over 2 million users on CWS which we might need to update with two new permissions "webRequestAuthProvider" and "offscreen" in MV3. Our version of the extension has "webRequest" and "webRequestBlocking" on mv2.
Will our extension get deactivated on users browser? Is there any way to test this behaviour without uploading to CWS?

Really appreciate your answers

Thanks.

wOxxOm

unread,
Nov 24, 2022, 6:12:28 AM11/24/22
to Chromium Extensions, blackout, wOxxOm, oliver.m...@gmail.com
None of webRequest**** permissions are mentioned in the source code that builds the warnings https://crsrc.org/chrome/common/extensions/permissions/chrome_permission_message_rules.cc
Many values for `permissions` don't have a warning, they exist to lessen the overhead of initializing the `chrome` object and to facilitate the review process.

Jackie Han

unread,
Nov 24, 2022, 11:59:29 AM11/24/22
to wOxxOm, Chromium Extensions, blackout, oliver.m...@gmail.com
Is "webRequestAuthProvider" a warning permission?

Comment 93 says:
Instead, introduce a new permission, `webRequestAuthProvider`, that
extensions can use if they want to handle the webRequest.onAuthRequired
event with a blocking (or asyncBlocking) listener. Like
`webRequestBlocking`, this permission does not add a new warning, as its
functionality is covered by the warning for the host permission (which
the extension requires in order to intercept the calls).

So it is not a warning permission. The warning depends on your host permission.


Is there any way to test this behaviour without uploading to CWS?

You have over 2 million users. In the future, I suggest you publish a beta version of your extension on CWS. Thus you can test it on beta version before publishing to stable version.


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/74abfa4f-70b6-49cf-a168-f262b1ec3dc2n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages