Saved passwords (HTTP Basic Auth) should work on http and https and across subdomains |
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce the problem: 1. Visit a site that has HTTP Basic Auth logins on both http and https versions, like http://bugs.icu-project.org/trac/login and https://ssl.icu-project.org/trac/login 2. Save a username/password on one version, like the http version. 3. Go to the https version and try signing in. What is the expected behavior? Chrome should suggest my username and password based on the one I used on the http clone of the site. What went wrong? Chrome does not suggest my password. Did this work before? N/A Chrome version: 62.0.3202.75 Channel: stable OS Version: Flash Version:
,
Oct 27 2017
A couple of thoughts: - The https credential should not be provided to an http page. The other way around is fine. - I am not sure whether we want to do PSL matching here. For password forms, we do that only after the user manually confirmed that the credentials should be filled. What do others think?
,
Oct 30 2017
This seems to be a feature request. Hence, marking it as untriaged for further inputs from dev team. Thanks...!!
,
Nov 2 2017
,
Nov 3 2017
I agree with #2. We should follow: * HTTP => HTTPS filling, but not vice versa. * PSL matching filling only after user action. Adding vabr@ as he worked on HTTP Auth, AFAIK.
,
Nov 8 2017
Unlike HTML forms, HTTP auth challenges have signon realm beyond just the origin. So where an HTML form is identified by the scheme, hostname and port, an HTTP auth challenge has scheme, hostname, port and a free-text string to be matched against the signon realm of the stored credentials. If we want to do PSL matching (e.g., considering pairs as a.google.com and b.google.com as related) we still need to maintain that the scheme, port and the free-text string need to match. As for scheme restrictions: I agree that we should never fill a https:-stored credential into a http:-issued auth challenge. I disagree that the other way round is OK -- see https://docs.google.com/document/d/1ei3PcUNMdgmSKaWSb-A4KhowLXaBMFxDdt5hvU_0YY8/edit#heading=h.bdtrfv54n08k (@chromium.org and @google.com accounts only) and bug 571580 where we put a lot of care to avoid unrestricted filling of http: credentials on https: sites. The one-off migration from http: to https: should work on HTTP auth credentials, and if it does not, we should fix it.
,
Jan 26 2018
,
Nov 29
vabr going hobby only -> reducing involvement. Please contact me directly in urgent matters. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by chrishtr@chromium.org
, Oct 26 2017