#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 , 5 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 , 5 years ago
Replying to Carlton Gibson:
Hi.
The link you've given implies that if
samesite
isNone
then 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 , 5 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 , 5 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
comment:5 by , 5 years ago
Needs tests: | unset |
---|---|
Owner: | changed from | to
Patch needs improvement: | unset |
Status: | new → assigned |
Version: | 2.2 → master |
comment:6 by , 5 years ago
Type: | Bug → New feature |
---|
comment:7 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:9 by , 4 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
samesite
isNone
then 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.)