Do you have a sample site that has this issue? If we receive fresh WWW-Authenticate headers on a request, we'll pop up the basic auth dialog. If we've previously authenticated against the same domain in the same connection, we should only be showing the dialog a single time.

Yup. In case the site or configuration where this happens isn't publicly accessible, could you send us a network log? Instructions for capturing a network log can be found here: https://dev.chromium.org/for-testers/providing-network-details

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Reporter: Could you please respond to comment# 4 by providing network logs, hence adding Needs-Feedback label to it.

Thanks!

This is my network logs, thank you for viewing.

Deleted: chrome-net-export-log-normal(cross-domain).json 96.6 KB

chrome-net-export-log-normal(cross-domain).json 96.6 KB View Download

Deleted: chrome-net-export-log-abnormal(non-cross-domain).json 75.5 KB

chrome-net-export-log-abnormal(non-cross-domain).json 75.5 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here's a quick summary of the responses seen from the two logs:

In the same-origin case (i.e. referrer and host are same-origin) I see the following request:

t=18336 [st=   0]   +URL_REQUEST_START_JOB  [dt=1249]
                     --> load_flags = 16384 (MAYBE_USER_GESTURE)
                     [...]
t=18463 [st= 127]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                         --> HTTP/1.1 401 UNAUTHORIZED
                             Server: nginx
                             Date: Fri, 31 Aug 2018 02:01:41 GMT
                             Content-Type: application/json
                             Content-Length: 63
                             Connection: keep-alive
                             WWW-Authenticate: Basic realm="Authentication Required"
                             Access-Control-Allow-Origin: *

From the network stack's perspective, the behavior when the response is seen is to bubble up the auth challenge if there are no cached credentials present. This will result in a prompt.

In the cross-origin case (i.e. referrer and host are cross-origin) I see the following request:

t=18809 [st=  0]   +URL_REQUEST_START_JOB  [dt=125]
                    --> load_flags = 17216 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | MAYBE_USER_GESTURE)
                    --> method = "GET"
t=18934 [st=125]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 401 UNAUTHORIZED
                            Server: nginx
                            Date: Fri, 31 Aug 2018 02:13:10 GMT
                            Content-Type: application/json
                            Content-Length: 63
                            Connection: keep-alive
                            WWW-Authenticate: Basic realm="Authentication Required"
                            Access-Control-Allow-Origin: https://ht.yunzhixi.cn
                            Vary: Origin

Note that the request flags are different now, and include DO_NOT_SEND_AUTH_DATA. The latter is an instruction to not send any Authorization headers in the response. Hence receiving a 401 challenge is a dead end. The error will be bubbled up to the caller without any prompting.



This behavior would be consistent with the request being made via XMLHttpRequest where the withCredentials flag is false. Could you confirm?

Yes, I didn't set up withCredentials, it should be false.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

asanka@ - Gentle ping...!!
Could you please provide any further input/s on the issue.
Thanks...!!

As per comment #13, adding 'TE-NeedsTriageHelp' and requesting 'Internals>Network>Auth' team to look into the issue and help in further triaging.

Thanks..