Implement "network.continueWithAuth" command
Categories
(Remote Protocol :: WebDriver BiDi, task, P2)
Tracking
(firefox122 fixed)
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: whimboo, Assigned: jdescottes)
References
(Blocks 3 open bugs, )
Details
(Whiteboard: [webdriver:m9], [wptsync upstream])
Attachments
(3 files)
This bug will take care of implementing the network.continueWithAuth
command.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Updated•1 years ago
|
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Assignee | ||
Comment 1•1 year ago
|
||
Before implementing this, I was looking at what DevTools show for a basic authentication flow, eg when you get a prompt and submit the correct credentials.
Firefox DevTools show only one request with status 200 and the final response.
Chrome DevTools show 2 requests, the first failing, with no response ; the second one with status 200 and the final response.
Since the behavior is inconsistent, I would like to check the expected events before going further.
Looking at the fetch spec, it seems that when we reach the auth prompt, we should run another fetch, and reuse its response as the response of the first fetch:
Set response to the result of running HTTP-network-or-cache fetch given fetchParams and true.
(from https://fetch.spec.whatwg.org/#http-network-or-cache-fetch)
So in terms of BiDi events, if we imagine a fetch on a URL with www-authenticate headers, it means we would get first:
- beforeRequestSent for the initial request
- responseStarted for the initial request
- authRequired for the initial request
At this point we imagine that we either have an intercept catching this and use continueWithAuth, or that the credentials are provided manually. So based on the fetch spec, we start a new fetch with the credentials set in the request headers, so we should now get:
- beforeRequestSent for the request with credentials
- responseStarted for the request with credentials
- responseCompleted for the request with credentials
And finally
- responseCompleted for the initial request (which should have the same response content as the new request)
James: does this sound right to you?
Comment 2•1 year ago
|
||
Hmm, so this is fun. The way that BiDi is currently integrated into fetch means that afaict for the request with auth you get a beforeRequestSent
and a responseStarted
, but you only get a single responseCompleted
for both requests, because we only run the "main fetch" algorithm once (the request with credentials calls directly into HTTP-network-or-cahce-fetch). That does seem like it might be problematically invariant violating, and we can likely fix it if it's a problem.
Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
Depends on D195673
Assignee | ||
Comment 5•1 year ago
|
||
Depends on D195675
Updated•1 year ago
|
Assignee | ||
Comment 6•1 year ago
|
||
Hi Olivia,
I'm having an issue on Android when trying to resume an authentication request.
BiDi can intercept requests right before the auth prompt is displayed, and then if we use the continueWithAuth command with action=default, the idea is that the browser should do the default behavior, meaning showing the auth prompt.
Technically, we use a wrapper in devtools to do the forwarding: https://searchfox.org/mozilla-central/rev/dc5027f02e5ea1d6b56cfbd10f4d3a0830762115/devtools/shared/network-observer/NetworkAuthListener.sys.mjs#62-69
First we get the prompt, and then we call prompt.asyncPromptAuth
on it. On GeckoView side, I saw that we are reaching AuthHandler:callDelegate
, but then it only seems to call onAuthPrompt
in GeckoSession.java which returns null. We never go into what seems to be the real code showing a prompt in BasicGeckoViewPrompt.
Do you have an idea about what could be wrong here?
Comment 7•1 year ago
•
|
||
Hi Julian,
Thanks for looking at GeckoView too!
We never go into what seems to be the real code showing a prompt in BasicGeckoViewPrompt.
Is this happening in automation? If that is the case, it looks like onAuthPrompt
isn't implemented in the test runner activity. GeckoView example activity code isn't shared with the test runner activity. So, if this is in automation, we will need to add an implementation in the test runner for automation too.
I also think to fully implement the prompt for WebDriver in the test runner, GVE and the other apps, we might also need to add some logic to the JavaScript side. I'm not sure if this one is a special case or not. For example, adding an auth prompt response. Here are the list of prompt names. I'm guessing this one might be under the asyncPromptAuth
name. We will also need to add some functionality/data to it and what it can return. This patch might be a useful outline of all the pieces too, if we need to go in that direction.
Assignee | ||
Comment 8•1 year ago
|
||
Thanks Olivia, that's really helpful!
Yes this issue happens on automation, when running wdspec tests (failing job on treeherder).
I will use your suggestions to try to fix this in Bug 1870263.
Updated•1 year ago
|
Comment 12•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/47c47a8b2b33
https://hg.mozilla.org/mozilla-central/rev/8b75870e1359
https://hg.mozilla.org/mozilla-central/rev/1a413f0496a4
Reporter | ||
Updated•11 months ago
|
Description
•