#30862: Explicitly set `secure` for SameSite: None cookies.
-------------------------------------+-------------------------------------
     Reporter:  Osaetin Daniel       |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  HTTP handling        |                  Version:  2.2
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
  cookies,request,response           |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Osaetin Daniel):

 Replying to [comment:1 Carlton Gibson]:
 > Hi.
 >
 > The link you've given implies that if `samesite` is `None` then we
 **must** set `secure` —
 
[https://github.com/django/django/blob/5d9cf79baf07fc4aed7ad1b06990532a65378155/django/http/response.py#L198-L201
 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

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30862#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ad44e0ce687073eb60fc7af20d92b450%40djangoproject.com.

Reply via email to