Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

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
Đính kèm ảnh chụp màn hình

Tất cả các câu trả lời (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)

Được chỉnh sửa bởi cor-el vào

Hữu ích?

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:

Hữu ích?

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

Hữu ích?

more options

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

Hữu ích?

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

Hữu ích?

more options

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

Hữu ích?

more options

I was already in "Cross Site Cookie blocking" mode

Hữu ích?

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.

Hữu ích?

more options

I'm not sure what you mean

Hữu ích?

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

Hữu ích?

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.

Hữu ích?

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.

Hữu ích?

Đặt một câu hỏi

Bạn phải đăng nhập vào tài khoản của bạn để trả lời bài viết. Vui lòng bắt đầu một câu hỏi mới, nếu bạn chưa có tài khoản.