Issue metadata
Sign in to add a comment
|
HTTP authentication broken for XMLHttpRequests
Reported by
lub...@gmail.com,
Feb 3 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36 Steps to reproduce the problem: 1. Have a web application secured with HTTP authentication 2. This web application makes requests via XMLHttpRequest 3. Boom What is the expected behavior? The web application can make XMLHttpRequests instead of failing. What went wrong? All XMLHttpRequests to a relative URL (e.g. /xmlrpc) fail with error 401 while static resources are being loaded successfully by the browser. The browser doesn't bother sending the already provided username/password (checked in Wireshark). It used to work until Chrome/Chromium 64 and it still works in Firefox. In Developer Tools / Network, the tooltip strangely shows that "null:null" auth data are used for these requests, while it doesn't reveal auth data for resource files. I checked the application source code, and it specifies just "/xmlrpc" for the URL. When I press F5, the browser suddenly forgets the authentication data and prompts again. This also didn't happen until Chrome 64. Did this work before? Yes 63 Chrome version: 64.0.3282.119 Channel: n/a OS Version: Flash Version: Shockwave Flash 28.0 r0
,
Feb 5 2018
lubosd@ Thanks for the issue. Request you to provide the URL of the web application where this issue can be reproduced which will help in further triaging. Thanks..
,
Feb 5 2018
,
Feb 19 2018
I've figured out the problem. When I make a request like this:
xhr.open('GET', '/someurl', true, undefined, undefined);
it works. But when I make a call like this:
xhr.open('GET', '/someurl', true, null, null);
it fails.
These two calls were previously treated identically, now the second one fails. You can see it in action here (user/password is test/test): http://ukvpn.dolezel.info/xhr.html
,
Feb 19 2018
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
,
Feb 20 2018
lubosd@ Thanks for the feedback. Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Stable 64.0.3282.168 able to reproduce the issue. Note: Issue is fixed on the latest Canary 66.0.3350.0 and Beta 65.0.3325.73. Reverse Bisect Information: ============================ Good Build: 66.0.3341.0 (Revision - 534605) Bad Build: 66.0.3340.0 (Revision - 534315) Unable to provide the Changelog URL after executing the per-revision script and Chromium bisect as all good builds were invoked. Hence providing the manual changelog URL from Omahaproxy. Changelog URL: ============== https://chromium.googlesource.com/chromium/src/+log/66.0.3340.0..66.0.3341.0?pretty=fuller&n=10000 From the above Changelog, suspecting the below Change https://chromium-review.googlesource.com/899382 yukishiino@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable as this is a recent regression. Please feel to remove the same if it is not applicable. Thanks..
,
Feb 20 2018
,
Feb 22 2018
lubosd@, please use the work around you've found in #4, and see the progress at bug 808018 . |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Feb 4 2018