#30862 closed New feature (fixed)
Explicitly SameSite: None cookies.
| Reported by: | Osaetin Daniel | Owned by: | Osaetin Daniel |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | cookies, request, response |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When setting cookies (with .set_cookie and set_signed_cookie) the default value for the samesite argument is None but the problem here is that Django doesn't do anything with the None value.
This behaviour used to be fine because most browsers assumed that a missing samesite attribute on a cookie meant None. But now, Chrome has issued a warning that samesite has to be explicitly set to None else the cookies won't be sent for cross-origin requests.
Change History (9)
follow-up: 2 comment:1 by , 6 years ago
| Component: | contrib.sessions → HTTP handling |
|---|---|
| Summary: | Explicitly set SameSite: None cookies → Explicitly set `secure` for SameSite: None cookies. |
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 6 years ago
Replying to Carlton Gibson:
Hi.
The link you've given implies that if
samesiteisNonethen we must setsecure— we're not doing that so we should add an extra clause in there.
Chrome has issued a warning that samesite has to be explicitly set to None else the cookies won't be sent for cross-origin requests.
Is this the same point? (It reads differently to me at first glance.)
My bad. The title of the ticket is misleading What I meant to say was to "allow the option to set 'same-site' to 'None'". At the moment, you can only set it to "Strict" or "Lax".
This statement "The link you've given implies that if samesite is None then we must set secure" is correct but I think the best thing is to be as flexible as possible. Although Chrome's warning has good intentions, it is not a global browser standard and other users (For reasons best known to them) might want to set the secure flag without samesite and vice-versa.
So in this case, the best option, In my opinion, is to allow "None" (as a string) without enforcing secure=True and at the same time preserve the current behaviour.
Perhaps I jumped the gun with this but I've already opened a PR that communicates my intentions: https://github.com/django/django/pull/11894
comment:3 by , 6 years ago
| Has patch: | set |
|---|---|
| Summary: | Explicitly set `secure` for SameSite: None cookies. → Explicitly SameSite: None cookies. |
OK, thank for the update. Makes sense. I've re-titled again accordingly.
...I've already opened a PR ...
Gun jumping of that kind we very much like. 🙂
Thanks.
comment:4 by , 6 years ago
| Needs tests: | set |
|---|---|
| Patch needs improvement: | set |
comment:5 by , 6 years ago
| Needs tests: | unset |
|---|---|
| Owner: | changed from to |
| Patch needs improvement: | unset |
| Status: | new → assigned |
| Version: | 2.2 → master |
comment:6 by , 6 years ago
| Type: | Bug → New feature |
|---|
comment:7 by , 6 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:9 by , 5 years ago
I created issue #31933.
I think this change should be backported to all working versions of Django, to allow setting SESSION_COOKIE_SAMESITE = 'None' manually in all versions, which are still in use until 2022.
Hi.
The link you've given implies that if
samesiteisNonethen we must setsecure— we're not doing that so we should add an extra clause in there.Is this the same point? (It reads differently to me at first glance.)