Release 104 Cross-site Redirect Issue
It appears with the latest update, 104.0, my customers are no longer able to log into their accounts with my web site. The console is showing the following warning:
Cookie "JSESSIONID" with the "SameSite" attribute value "Lax" or "Strict" was ommited because of a cross-site redirect.
So the JSESSION ID cookie is being omitted, which is preventing the login process from working correctly.
Going into settings => Privacy and Security and unchecking cookies from the Custom setup still doesn't fix the issue.
The behavior seems to be inconsistent as the same version of Firefox works fine for me on one machine, but generates this warning another, even with the same settings.
Can you explain in more detail why this is happening and steps to fix it?
Thank you, M. Warble
All Replies (11)
It has been a while since we had threads on the SameSite attribute. Could you check the following preference on the problem Firefox:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.
More info on about:config: Configuration Editor for Firefox. The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future. Since we are resetting to default, I feel comfortable mentioning it.
(2) In the search box in the page, type or paste network.cookie.sameSite.laxByDefault and pause while the list is filtered
(3) If the network.cookie.sameSite.laxByDefault preference is bolded and has a value of true, double-click it (or use the reset button at the right end of the row) to restore the default value of false
Was that customized?
That value is set to false.
Hmm, is it possible the cookie's SameSite attribute has changed since Firefox stored it? If you haven't already -- on the broken Firefox only:
Remove the site's cookies (save any pending work first): While viewing a page on the site, click the lock icon at the left end of the address bar. After a moment, a "Clear Cookies and Site Data" button should appear at the bottom. Go ahead and click that. Firefox will ask you to confirm; go ahead and confirm.
Repeat on the login page as well as the main site. If the address bar doesn't show the second host name for login, it may be a frame. Right-click in the login form and if you find a "This Frame" item on the context menu, expand that and click Open Frame in New Tab. Then you should be able to more easily manage permissions and data for the second server.
Then try starting from the beginning. Any improvement?
If the problem appears with fresh cookies, then it would be helpful to understand whether Firefox is correctly flagging this as a cross-site cookie, or whether that is a bug. That may involve following very specifically the redirects involved.
A few questions maybe you can answer:
1. Any idea why the JESSIONID cookie would work fine from one machine, but not another using the same version of Firefox with the same settings?
2. Can any of the Firefox settings be set so the cookie is not ignored? I thought disabling cookie blocking completely would fix the problem, but it doesn't.
3. I've cleared all the old cookies. Is there a way using Firefox to view the redirects involved?
m.warble said
A few questions maybe you can answer: 1. Any idea why the JESSIONID cookie would work fine from one machine, but not another using the same version of Firefox with the same settings?
Not yet.
2. Can any of the Firefox settings be set so the cookie is not ignored? I thought disabling cookie blocking completely would fix the problem, but it doesn't.
If a site has SameSite=strict or SameSite=lax in the cookie, this is analyzed by separate logic than the tracking protection feature.
3. I've cleared all the old cookies. Is there a way using Firefox to view the redirects involved?
If you open the Network Monitor (Ctrl+Shift+E) in the tab before starting the login process, you can track every request. You'll need to click the little wheel icon at the right end of the filter row and make sure Persist Logs is enabled (otherwise, each new page load clear the log).
The redirects usually show 301 or 302 as the server response code.
Other browsers are similar if you want to compare, but they may not have this direct shortcut.
You can check for issues with Total Cookie Protection.
My login process does preform a redirect, but it's a redirect to a page under the same domain. The only problem I can see is that the redirect is being performed as "http" instead of "https".
Would this type of redirect be expected to cause this problem?
m.warble said
My login process does preform a redirect, but it's a redirect to a page under the same domain. The only problem I can see is that the redirect is being performed as "http" instead of "https". Would this type of redirect be expected to cause this problem?
The protocol might be the issue. According to https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite:
Cookies from the same domain are no longer considered to be from the same site if sent using a different scheme (http: or https:).
But you may be experiencing a problem where Firefox remembers or inherits HTTP from the original request even when the login and subsequent redirect are on HTTPS. That sounds familiar from another thread.
The http vs https appears to be the problem. After explicitly specifying https for the redirect, it worked.
I'm just confused as to why this isn't consistent behavior on different machines with the same Firefox settings.
A user might have customized the value of the network.cookie.sameSite.schemeful preference to false to bypass this protection, due to encountering this problem on another site in the past. Definitely not recommended...