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

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

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

Firefox claims SameSite is set to Lax, while set-cookie contains SameSite=None and Secure

  • 1 απάντηση
  • 0 έχουν αυτό το πρόβλημα
  • 1 προβολή
  • Τελευταία απάντηση από Øyvind Wergeland

more options

Our backend sets a cookie for maintaining login sessions with SameSite=None and Secure (to support loading our front-end from localhost for developers and from a third party domain for PR previews).

This is the respose header:

set-cookie: ESESSIONID=<redacted>; Secure; HttpOnly; Path=/; SameSite=None; Max-Age=86399

However, Firefox does not send the cookie back with requests, but logs this error in the console:

Cookie “ESESSIONID” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”.

We have worked around the issue by configuring exceptions in the Security & Privacy settings, but I am curious to why Firefox rejects the cookie with this error message.

Our backend sets a cookie for maintaining login sessions with SameSite=None and Secure (to support loading our front-end from localhost for developers and from a third party domain for PR previews). This is the respose header: set-cookie: ESESSIONID=<redacted>; Secure; HttpOnly; Path=/; SameSite=None; Max-Age=86399 However, Firefox does not send the cookie back with requests, but logs this error in the console: Cookie “ESESSIONID” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. We have worked around the issue by configuring exceptions in the Security & Privacy settings, but I am curious to why Firefox rejects the cookie with this error message.

Όλες οι απαντήσεις (1)

more options

I am not sure what you mean by "the site in question"? In production our back-end and front-end are served from two different subdomains of our domain, and here Firefox works with default settings.

The issue occurs when developers run the front-end from localhost (served by webpack-dev-server), and logs into our back-end. The ESSESSIONID cookie is set in the response to our callback endpoint for authorization code flow in our back-end.

It takes some effort to set up a public repro, and we are able to work around it, but I am curious to why Firefox logs an error that seems to contradict the set-cookie header.