Issue metadata
Sign in to add a comment
|
HTTP Basic Auth Credentials being automatically attached to XhrRequests from dialog
Reported by
max.kra...@bcgdv.com,
May 8 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: 1. Access domain requiring basic auth and enter correct username and password 2. Send XhrRequest to api on this domain 3. Request has authorization header attached and cannot be deleted manually What is the expected behavior? XhrRequest is sent without the basic authentication (authorization) header attached What went wrong? The basic authentication header was attached after the XhrRequest was executed by our javascript, which had no authorization header included. Did this work before? Yes 65.0.3325 Does this work in other browsers? Yes Chrome version: 66.0.3359.139 Channel: stable OS Version: OS X 10.12.6 Flash Version: If you're unable to reproduce it, we will happily create a basic sample for you. Thanks for your support!
,
May 9 2018
Thanks for filing the issue! @Reporter: As per comment#0 steps to reproduce the problem, to test the issue from our end we need the sample URL and valid login credentials to confirm the issue, if possible could you please provide the sample URL and valid login credentials which helps us in further triaging it. Thanks!
,
May 9 2018
Hi Viswa, Thanks for the response. Please find at the following gist a very simple sample project which you can use to verify! In order to run, you'll need ruby and bundle. - `gem install bundle` - `bundle install` - `ruby test.rb` # to start the server Then navigate to localhost:8080 and you will be asked for basic auth credentials (admin, admin). Enter the basic auth credentials, and you'll be shown a button to send a basic XHR request as defined in the index.html. In the index.html after clicking the button, you'll be shown the request headers from the outgoing request. As you can see the username and password you entered before are contained in this request, even though they were not set in the request itself. https://gist.github.com/maxkramerbcgdv/7329cc800ac5d92e98b89cae15830e79
,
May 9 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
,
May 10 2018
As per comment# 3 from the reporter, to test and confirm the issue it needs ruby and bundle, as the setup is not available at TE end, hence adding TE-NeedsTriageHelp label for further investigation from DEV team on this issue. Thanks!
,
May 10 2018
I'm confused about what has actually changed here. XHR has always used cached credentials for same-origin requests.
,
May 10 2018
Hi @ricea, from what we have seen, the request didn't include these credentials in the previous version of Chrome, but seems to be sending them since we updated. Is there a way that we can disable the usage of these cached credentials?
,
May 14 2018
I tested Firefox and Chrome version 59 with the provided sample project. They both have the same behaviour as Chrome 66.
,
May 14 2018
Closing as "cannot reproduce". I will reopen if there is new information about what actually changed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, May 8 2018