Set-Cookie does not set the cookies when it's done after a HTTPs to HTTP transition
Reported by
aliakyu...@gmail.com,
Mar 24 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Steps to reproduce the problem: I have a web application running on custom web server on a custom device. This web application has a login page. After, the user provides his/her credentials, these credentials are sent via AJAX to server and in response of AJAX, server sends Set-Cookie header to set cookie in client. Client includes this cookie in its further requests. This is typical workflow of many web applications. This case works well in all other browser and also in Chrome till I do the following: 1. Open the web application in HTTPS. Login. Set-Cookie in response successfully creates the cookie on browser. 2. Logout. 3. Go to address bar and change HTTPS to HTTP. Web application loaded again. 4. Now, Login again. Response header contains Set-Cookie. What is the expected behavior? I expect that the Set-Cookie in response header must set cookies on browser after the HTTPS to HTTP transition. What went wrong? The Set-Cookie, received in login response does not set cookie on browser. So It's not possible to login to application anymore until I close the browser. When I open the browser again and connect via HTTP, everything works fine. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.75 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Thanks for your time.
,
Mar 27 2017
This looks like out of scope for TE, hence adding the respective label for it to triage further.
,
Mar 27 2017
[+mkwst]: Presumably related to the secure cookies change.
,
Apr 5 2017
@mkwst, any idea where this should be routed?
,
Apr 6 2017
To me. :) aliakyurek@: Does the `set-cookie` header attempt to set a cookie with a `secure` attribute? If so, it's expected that it would be blocked if sent from a non-secure origin (as per https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01). If that's not the explanation, then I'm happy to dig in.
,
Apr 6 2017
@mkwst: I too face the same issue and have raised it in another thread. https://bugs.chromium.org/p/chromium/issues/detail?id=698839#c2 In my case, the 'secure' attribute was not set from non-secure origin. I believe @aliakyurek also hasn't set it.
,
Apr 10 2017
In my case, the 'secure' attribute was also not set from non-secure origin. My issue is completely same as this comment: https://bugs.chromium.org/p/chromium/issues/detail?id=698839#c2
,
Apr 12 2017
Re #7: This sounds like it is "Working as Intended" as of the implementation of https://www.chromestatus.com/feature/4506322921848832
,
Apr 12 2017
To elaborate a bit, an insecure page cannot set a cookie named "EXAMPLE1" if there exists a secure cookie named "EXAMPLE1".
As explained in the spec:
If the newly created cookie's "secure-only-flag" is not set,
and the "scheme" component of the "request-uri" does not
denote a "secure" protocol, then abort these steps and ignore
the newly created cookie entirely if the cookie store
contains one or more cookies that meet all of the following
criteria:
1. Their "name" matches the "name" of the newly created
cookie.
2. Their "secure-only-flag" is set.
3. Their "domain" domain-matches the "domain" of the newly
created cookie, or vice-versa.
4. The "path" of the newly created cookie path-matches the
"path" of the existing cookie.
The "Logout" step in the original repro needs to use a HTTPS page to REMOVE the secure cookie before navigation to the HTTP page if the HTTP page is to be allowed to set the cookie.
,
Apr 20 2017
OK. Thank you very much. Now I understand that this is a feature and the comment 9 proposes a solution how to fix the issue.
,
Oct 4
(Unassigning myself, marking untriaged in preparation to retriage with folks who will do a better job taking care of cookies than I've been able to)
,
Jan 15
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by manoranj...@chromium.org
, Mar 24 2017Labels: Needs-Triage-M57