Set-Cookie from redirect ignored/not used in following request
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: esevecke, Unassigned)
Details
Attachments
(1 file)
|
2.35 MB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
Used standard spring boot security settings to secure a site. The login page is displayed if I request a secured page. Then entered valid credentials.
Actual results:
The request to the secured page results in an 302-redirect to the login page. The redirect contains a Set-Cookie for the session id cookie. Firefox requests the login page without setting this cookie in the request headers.
Expected results:
The request to the login page should contain the cookies from the redirect response.
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•5 years ago
|
||
Hello Reporter,
Which version of firefox did you use which encounter the failure?
Does it work well before?
firefox version 74.0 (64-Bit) on windows 10 pro.
I don't know if this worked well before. But it worked well in other browsers (current chrome and edge tested).
Typo: Last comment "worked will in other browsers" should be "works well in other browsers".
|
|
||
Comment 5•5 years ago
|
||
Could you provide a HTTP log to move forward?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Thanks.
|
|
||
Comment 8•5 years ago
|
||
Necko stack seems right. I'd like to change the component to have more insights.
|
||
Comment 9•5 years ago
|
||
Can I ask you to provide a similar log but with cookie messages enabled? You can use: MOZ_LOG=cookie:5
Or, if you can tell me more about how to reproduce the issue. I suspect this happens with a particular website, and not in general.
|
Reporter | |
Comment 10•5 years ago
|
||
I think I have found the reason: The URL I used is localhost with some port and the relevant cookie is JSESSIONID.
But there seem to exist another variant of this cookie in the browser. And the cookie I expect to be sent by the next request has some kind of conflicting attributes which hides this cookie by the one existing in the browser (note: the cookie existing in the browser is also not used in the request).
After clearing all cookies everything works as expected.
From my point of view this ticket can be closed.
Maybe a warning message could be written to the console in case that a cookie will not be used as a result of this kind of conflicting definitions.
Hint: Maybe the "hiding" reason is that the cookie exists in the browser with the secure flag set and my test doesn't use ssl.
If this is the reason: Is this the correct behaviour? Shouldn't the insecure cookie replace the secure cookie as it is from a response from an insecure request?
|
|
Reporter | |
Comment 11•5 years ago
|
||
I have reproduced it this way:
clear all cookies.
restart the tomcat servicing http at some port, request the secured page with http: OK. The requested page is displayed after logging in.
restart the tomcat servicing https at the same port, request the secured page with https: OK. The requested page is displayed after logging in.
restart the tomcat servicing http at the same port, request the secured page again with http: ERROR. Instead of the requested page the login page is displayed again.
clear all cookies.
request the secured page with http: OK. The requested page is displayed after logging in.
|
||
Comment 12•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
||
Updated•4 years ago
|
|
||
Comment 13•4 years ago
|
||
Hello, I am not 100% sure but seems related to https://bugzilla.mozilla.org/show_bug.cgi?id=1465402.
I will repost my comment here.
I got this bug too on Firefox 81.1.4 running on Android 10.
Also I noticed that this bug vanishes when clearing cookies manually or visiting a different url than the one specified in the redirect path.
Steps to reproduce:
- Clear all nav data
- Visit url redirecting to same domain with set cookie samesite="strict"
- Check cookie is not sent in request headers
- Manually delete cookies for said domain
- Visit url from step 2
- Notice new cookie is set and correctly sent with redirection
Instead of manually deleting cookies, you can also go to a different url on the same domain and then come back to the redirection target. Works also when only changing query parameters.
Description
•