Αναζήτηση στην υποστήριξη

Προσοχή στις απάτες! Δεν θα σας ζητήσουμε ποτέ να καλέσετε ή να στείλετε μήνυμα σε κάποιον αριθμό τηλεφώνου ή να μοιραστείτε προσωπικά δεδομένα. Αναφέρετε τυχόν ύποπτη δραστηριότητα μέσω της επιλογής «Αναφορά κατάχρησης».

Μάθετε περισσότερα

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

  • 12 απαντήσεις
  • 0 έχουν αυτό το πρόβλημα
  • 1 προβολή
  • Τελευταία απάντηση από jscher2000 - Support Volunteer

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
Συνημμένα στιγμιότυπα

Όλες οι απαντήσεις (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)

Τροποποιήθηκε στις από τον/την cor-el

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:

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

more options

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

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

more options

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

more options

I was already in "Cross Site Cookie blocking" mode

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.

more options

I'm not sure what you mean

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

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