Using Node Express-Sessions to set cookie "httpOnly: true, secure: true, SameSite: "None" FF blocks authorization
My web site My web site allows user to login with .ejs Sign-up/Sign-in pages then delivers a React page. This works in Chrome and Safari. Https/SSL are provided by my host A2Hosting.
Firefox warns "Cookie “connect.sid” does not have a proper “SameSite” attribute value" when the cookie is set and then blocks the react page after login. If I enter the route that leads to the react page directly I can login and don't get the warning. In both cases the Storage tab in Dev tools shows the same settings for the cookie.
I made sure to remove any cookies for my site before testing the second scenario. I have tested this on Windows, Linux and Android versions of Firefox with the same results.
Here is my Express-Session instantiation ``` app.use(expressSession({
store: new pgSession({
pool: pool,
tableName: 'session'
// Insert connect-pg-simple options here
}),
secret: process.env.SECRET,
resave: false,
saveUninitialized: false,
cookie: {
httpOnly: true, Secure: true, SameSite: "None", path: ['/'], maxAge: 60 * 60 * 1000 * 5 } // Insert connect-pg-simple options here
})) ``` I've tried changing the path to include the react app route, I've added it to Cors white list and I converted it to open with an .ejs file instead of .html with no results.
Thanks for your support and for a great browser
Alle svar (12)
THIS IS A RE-POST NOT A SOLUTION
Firefox warns "Cookie “connect.sid” does not have a proper “SameSite” attribute value" when the cookie is set and then blocks the react page after login. If I enter the route that leads to the react page directly I can login and don't get the warning. In both cases the Storage tab in Dev tools shows the same settings for the cookie.
I made sure to remove any cookies for my site before testing the second scenario. I have tested this on Windows, Linux and Android versions of Firefox with the same results.
(edit: fixed layout - please do not press Enter, but let Firefox handle wrapping - cor-el)
Ændret af cor-el den
Hi Rich, starting a line with a space triggers < pre > styling, i.e., no line wrap. This is making it hard to read your posts.
Is there any hostname difference between the page with the sign-in form and the application that requires authentication? Firefox's Total Cookie Protection may be causing the issue in that case. More info in the following articles:
Thanks, good to know about 'starting a line with a space'.
Both the app and the sign-in form are hosted on the same server. The only real difference is the the url for the first page is (Like) www.example.com and the app url is like www.example.com/app-name. Seems like the same host to me, other wise how do you serve multiple pages using cookies.
I suspected this might be the problem, I was hoping someone there had a solution. I looked at the 2 links you sent and they really only addressed the user settings.
Thanks, Rich
Yes, TCP is a user setting, but it would be useful to know whether that is causing the problem.
I forgot to mention. I turned off enhanced tracking in my browser for this site a while ago and it didn't make a difference and I wouldn't want to force my users to trust me not to track them and turn off enhanced tracking.
Rich
Okay, if only one host is involved, SameSite is irrelevant so you could test without it and see whether that makes any difference.
The idea is to determine whether the console message about the value of SameSite is relevant by setting the cookie without setting SameSite (the browser default will apply instead).
On follow up: The browser seems to default to "None" no mater what it's set to, except in the case where SameSite: 'lax' and then it fails with a 503. Chrome seem to be the opposite: SameSite is blank, no matter what its set to in Express-Session. FF seems to be case sensitive 'Lax' but not 'lax'.
I added an image from one of the 'lax' crashes.
I'm not sure why you got a 503 response. https://developer.mozilla.org/docs/Web/HTTP/Status/503
If it's similar to 500 response, could you compare the Request Headers from a working request and see whether you can detect a difference?
Also, does your other browser send a GPC header? Some sites hate GPC. This is related to the "Do not sell my information" setting. See: Global Privacy Control.
Du skal logge ind på din konto for at svare på et indlæg. Start et nyt spørgsmål, hvis du ikke har en konto endnu.