Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Using Node Express-Sessions to set cookie "httpOnly: true, secure: true, SameSite: "None" FF blocks authorization

more options

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

[[futureonreview.com|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
Ama-screenshot ananyekiwe

All Replies (12)

more options

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)

Okulungisiwe ngu cor-el

Helpful?

more options

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:

Helpful?

more options

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

Helpful?

more options

Yes, TCP is a user setting, but it would be useful to know whether that is causing the problem.

Helpful?

more options

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

Helpful?

more options

Ok, I just disabled cookie blocking completely with no effect.

Helpful?

more options

I was already in "Cross Site Cookie blocking" mode

Helpful?

more options

Okay, if only one host is involved, SameSite is irrelevant so you could test without it and see whether that makes any difference.

Helpful?

more options

I'm not sure what you mean

Helpful?

more options

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).

Helpful?

more options

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.

Helpful?

more options

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.

Helpful?

Buza umbuzo

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.