Credentials from continueWithAuth are reused for subsequent requests

[juliandescottes]

Spawned from https://bugzilla.mozilla.org/show_bug.cgi?id=1977378

On Firefox, if a client uses network.continueWithAuth to successfully authenticate, the same credentials can then be reused for the upcoming requests.
Quickly checking the http and fetch spec, this seems correct because:

• BiDi's continueWithAuth will set the response's authentication credentials (spec)
• fetch will proceed to create an authentication entry for request and realm (spec)
• http considers valid credentials as applicable to other requests for the same realm (spec):

  If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

Assuming my understanding of the spec is correct we should still discuss if this behavior is good enough for testing / automation purposes.
Do we want to give users control over how authentication entries are stored (eg have a flag on continueWithAuth so that the entry is not persisted?) or add another command to allow to manage the stored credentials (eg to clear it, or to disable storing credentials).

[juliandescottes]

Notes from the working group meeting:

18:43 jdescottes: using continue with auth will store credentials. They will be reused for next requests. Can be annoying for testing authentication in details? Do we want to add a way to clear credentials, or to avoid storing credentials
18:43 ack sadym
18:43 * Zakim sees no one on the speaker queue
18:44 sadym: trying to find where they are stored
18:46 jdescottes: see https://fetch.spec.whatwg.org/#biblio-http:~:text=If%20isAuthenticationFetch%20is%20true%2C%20then%20create%20an%20authentication%20entry%20for%20request%20and%20the%20given%20realm%2E this is where the authentication entry is created
18:46 jdescottes: is it interesting to be able to clear credentials?
18:47 jimevans: can be interesting, not sure if that should be a flag on the command or a separate command.
18:48 sadym: no scenarios are blocked on this you can always create another user context etc...
18:48 jdescottes: correct
18:49 jimevans: a clear credentials sounds preferable, this way we can stay close to what the browser would normally do. But a way to clear the credentials would be useful

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed https://github.com/w3c/webdriver-bidi/issues/980.

The full IRC log of that discussion

<whimboo> topic: https://github.com//issues/980
<whimboo> github topic: https://github.com//issues/980
<whimboo> RRSAgent: make minutes
<whimboo> make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/08/13-webdriver-minutes.html whimboo
<whimboo> make minutes
<whimboo> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/08/13-webdriver-minutes.html whimboo
<sadym> jdescottes: spec don't respect `download` attribute on links. We propose to emit download events.
<sadym> jdescottes: question is do we want to add navigation information fo such downloads from the links, and if so, what it should be
<sadym> q+
<whimboo> q?
<sadym> ack next
<whimboo> q?
<sadym> sadym: it seems to be logical to have a new navigation ID and the URL of the dowanloadable content
<whimboo> q+
<jdescottes> q+
<jdescottes> ack whimboo
<sadym> whimboo: what should happen if user clicks a link with download attribute which leads to redirect
<whimboo> q?
<jdescottes> q-
<jdescottes> q+
<sadym> jimevans: we want to capture all the downloads including those started by `download` attribute. WRT redirects, IDK what is the right answer
<jdescottes> ack jdescottes
<jimevans> q+
<sadym> jdescottes: in case of download link, do we want to push history state, or generate a fake navigation?
<jdescottes> ack jimevans
<sadym> jimevans: when you click on the link with download, does it add an entry to the browser history when you click "backward-forward"? If it does not, we probably hsould not.
<jdescottes> q+
<sadym> jimevans: when you click on the link with download, does it add an entry to the browser history when you click "backward-forward"? If it does not, we probably should not.
<jdescottes> ack jdescottes
<sadym> jdescottes: it does not create links with download attribute, but IDK if it does for links with `download` header attribute
<sadym> AI: I will test it and follow up in the issue
<jimevans> q+
<jdescottes> ack jimevans
<sadym> jimevans: for me as one who writes the test, I expect the history exposed to the test to mimic the history in the real browser.
<sadym> github topic: https://github.com//issues/982
<whimboo> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/08/13-webdriver-minutes.html whimboo
<sadym> jdescottes: when you download the link several times, it adds a counter, however Chrome does not expose that real filename. Should we expose the real filename? Are we OK with exposing the real filename?
<whimboo> q+
<sadym> sadym: it probably a bug in Chrome, but IDK if we can fix it
<jdescottes> ack whimboo
<sadym> whimboo: we can expose the name at the moment the download finished
<sadym> we should know the filename by that time
<jdescottes> q+
<jdescottes> ack jdescottes
<sadym> jdescottes: from Firefox point of view, we have the information early. The question is if we want to send that information earlier. From our side both approaches are fine.
<sadym> I'm going to update WPT tests to avoid running into this issue
<sadym> github topic: https://github.com//issues/983
<sadym> jdescottes: Chrome prohibits some headers in `continue request` are prohibited, like `Host`. This creates critical differences in browsers' behavior.
<jdescottes> https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/header_util.cc;l=32-61;drc=98344435860d41977208fb875298162993ea091f
<sadym> accroding to the spec, we should update them
<sadym> sadym: from Chrome perspective, we have some workarounds for some headers like Referer, but IDK about Host. We should consider data from the BiDi client safe, and provide whatever they want to.
<sadym> jdescottes: I'm going to check if it works like that wit hCDP
<sadym> jdescottes: I'm going to check if it works like that with CDP
<sadym> let's continue discussion in the issue
<sadym> next topic: https://github.com//pull/948
<jdescottes> scribe: jdescottes
<jdescottes> sadym: feature requested by users is setting network conditions. Started with offline mode. Technically can be done with Network Interception. Will be difficult to specify bandwidth etc.
<jdescottes> sadym: talking about offline: several aspects : network requests and navigator online. With network interception we cannot influence navigator online, bur we can handle requests
<jdescottes> sadym: currently navigator online is defined in a way which should return false if the user can't reach the network. Unclear behavior
<jdescottes> sadym: proposal is to add a hook `is offline` so that the html spec can call this to know what to return
<jdescottes> q+
<jdescottes> ack jdescottes
<jdescottes> jdescottes: hook for html spec sounds good to me, especially since we can't block all network for now
<jimevans> q+
<jdescottes> sadym: should we split or land everything in one PR
<jdescottes> jimevans: can be more work, but I would prefer to see the full implementation landed at once. I would expect everything to behave as offline/online when setting this emulation.
<jdescottes> sadym: sounds good
<jdescottes> next topic: https://github.com//issues/968
<jdescottes> github topic: https://github.com//issues/968
<sadym> q+
<jimevans> q-
<jdescottes> jdescottes: using continue with auth will store credentials. They will be reused for next requests. Can be annoying for testing authentication in details? Do we want to add a way to clear credentials, or to avoid storing credentials
<jdescottes> ack sadym
<jdescottes> sadym: trying to find where they are stored
<jdescottes> jdescottes: see https://fetch.spec.whatwg.org/#biblio-http:~:text=If%20isAuthenticationFetch%20is%20true%2C%20then%20create%20an%20authentication%20entry%20for%20request%20and%20the%20given%20realm%2E this is where the authentication entry is created
<jdescottes> jdescottes: is it interesting to be able to clear credentials?
<jdescottes> jimevans: can be interesting, not sure if that should be a flag on the command or a separate command.
<jdescottes> sadym: no scenarios are blocked on this you can always create another user context etc...
<jdescottes> jdescottes: correct
<jdescottes> jimevans: a clear credentials sounds preferable, this way we can stay close to what the browser would normally do. But a way to clear the credentials would be useful
<sadym> q+
<jdescottes> sadym: can users clear their tokens via UI?
<jdescottes> jimevans: probably and we should have a way to replicate that with the test
<jdescottes> next topic: Note about unsubscribing and getting rid of user contexts
<jdescottes> jimevans: there is a note about getting rid of user contexts when unsubscribing, we should do it asap
<jdescottes> jimevans: it's in https://www.w3.org/TR/webdriver-bidi/#type-session-UnsubscribeByAttributesRequest
<jdescottes> jimevans: will file an issue
<jdescottes> make minutes
<jdescottes> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/08/13-webdriver-minutes.html jdescottes

[juliandescottes]

To summarize the discussion from the last meeting, the group is favor of adding a command to clear credentials.