Proposal: Persistent Authentication

[erosman]

Proposal: Persistent Authentication

Background

Extensions use webRequest.onAuthRequired.addListener in the background script to provide authentication. In MV3, when the background script is unloaded, restarting it, retrieving the necessary data asynchronously from the storage, and processing the data, can take up some time, which results in the unwanted authentication popup from the browser.

Ideally, a persistent method to provide the authentication data is needed.

Some APIs such as Menus and Scripting already support persistent data.

Proposal

Create a method to provide persistent authentication data

Suggestions

1. Persistent onAuthRequired

Make the listener and its data persistent

Here is an example of setting persistent rules that browser would handle.
It can be set under proxy.settings which would mean another extension won't interfere with it once 'controlled_by_this_extension' is set (or have a per-extension setting).

proxy.settings.authentication = [
  {host, port, username, password},
];

// --- or
webRequest.onAuthRequired.rules = [
  {host, port, username, password},
];

2. declarativeNetRequest

Adapt DNR to provide persistent authorisation data

The rule-based DNR approach (versus an event-based one) might prove to be more efficient in the long run and eliminate the need for a webRequest.onAuthRequired.addListener.

See also:

• Proposal: Introduce rule-based proxy authentication as an alternative to webRequest.onAuthRequired
• DNR & Proxy
• Supply credentials for proxy authorization in MV3
• webRequest API alignment and support in MV3

[Rob--W]

Preface: I am restricting the discussion to proxy, because regular network requests can already receive authentication details through DNR, via #264 (comment). If the discussion should apply more broadly, please clarify.

In today's meeting (#750) I mentioned Chrome's proxy API as an example of a declarative proxy API. Upon double-checking, I noticed that it does not support authentication, however. It could be added, and was requested in #264 before.

It sounds like a declarative proxy setting, or even a flag to remember the authentication for a certain amount of time (or until an error or explicit invalidation), potentially restricted to a specific origin and browsing profile, etc.) would fulfill the request to make the proxy details "persistent".

[erosman]

The issue is "How to provide proxy authentication when the background script is unloaded" (in MV3).

• The issue is the delay in authentication due to reloading of the background script
• The bug (as referred to in (Publish minutes of 2025-01-16 meeting #750), is observed on Chrome MV3, at the moment (See: Authentication does not work in Chrome for HTTP proxies)
• Firefox MV2 has no issue
• Firefox MV3 has not been tested

Preface: I am restricting the discussion to proxy, because regular network requests can already receive authentication details through DNR, via #264 (comment). If the discussion should apply more broadly, please clarify.

Indeed, the request is centred around Proxy authentication.

In today's meeting (#750) I mentioned Chrome's proxy API as an example of a declarative proxy API. Upon double-checking, I noticed that it does not support authentication, however. It could be added, and was requested in #264 before.

It would be useful and match the Firefox proxy.onRequest API method of providing authentication.

However, there is a major difference.
Firefox's proxy.onRequest is a background extension process (which can get unloaded in MV3) while Chrome’s proxy is a browser setting that should remain in force even when extension’s background is unloaded.

It sounds like a declarative proxy setting, or even a flag to remember the authentication for a certain amount of time (or until an error or explicit invalidation), potentially restricted to a specific origin and browsing profile, etc.)

Please note that the authentication is not limited to a single credential for a single requester. Multiple authentications for multiple proxies may need to be provided simultaneously. Furthermore, different credentials may be needed for the same requester which would make caching it by the browser impractical.

Currently, the only caching option is the rule-based caching. DNR was suggested as the rules will stay in force even when background script/service-worker is unloaded.

[erosman]

See also:

• MV3 onAuthRequired is not triggered by requests within service worker
• MV3 onAuthRequired is not triggered by requests made by extension pages [40880379] - Chromium
• onAuthRequired is not triggered on requests served by a service worker [40870289] - Chromium
• MV3 onAuthRequired is not triggered by requests made by extension pages [40880379] - Chromium
• onAuthRequired event doesn't fire for requests sent from extension on MV3
• Proxy asks for username and password, despite being already correctly set inside ZeroOmega's configuration
• Add headers using declarativeNetRequest only if the request is being proxied