Issue metadata
Sign in to add a comment
|
Chromium dropped support for embedded credentials in subresource requests.
Reported by
fur...@gmail.com,
Jul 3 2017
|
||||||||||||||||||||||||
Issue description
Chrome Version : 59.0.3071.115
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: No
Firefox: No
IE: No
What steps will reproduce the problem?
(1) Connect to a website with embedded credential from your bookmarks
(2) Be amazed that nothing works.
What is the expected result?
Chrome should behave as it did in the past
What happens instead?
Chrome doesn't behave as it did in the past
I suppose I can understand why Chromium decided to drop support for embedded credentials in subresource requests. This can leak passwords because Chromium doesn't encrypt bookmark storage (I assume). What is not great is how this is handled. Handling it as "network error" is weird because it's not a network error (it's a design/security decision). Also there's no clear and obvious error message in the window, the resources actually load but JS is not executed ; so you look at an unpopulated page which would mislead the user in believing the problem lies with the website. You have to actually open the dev tools and go aaaaaall the way to the bottom to find a warning (not an error) that this feature is deprecated (but already enforced it seems) by following the provided link: https://www.chromestatus.com/feature/5669008342777856
I feel that the very least should be to document this and provide a workaround for users who accept the risk.
,
Jul 5 2017
Duping this into issue 731618; the interaction between relative URLs and top-level documents with embedded credentials was indeed unintentional. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by cbiesin...@chromium.org
, Jul 4 2017