Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

So new iOS and Mac minor versions were launched, but issue is still there.
Created a new bug ticket on Webkit and they're being able to reproduce 
better the problem: https://bugs.webkit.org/show_bug.cgi?id=196375
Hope they can reach a solution soon!

Florian, you mean a blog post on Django's blog or anywhere else?

On Tuesday, March 19, 2019 at 5:58:01 AM UTC-3, Florian Apolloner wrote:
>
>
>
> On Monday, March 18, 2019 at 10:50:17 PM UTC+1, Flávio Junior wrote:
>>
>> What are the next steps?
>> A warning at the docs for these settings? 
>>
>
> I guess that is the big question. We'd have to remove the warning 
> "soonish" again I guess once safari is fixed (after all one wants the added 
> security benefit). Maybe a blog post? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aebf5595-33e0-4ad2-b247-8db0366bb308%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

Hey Mat, thanks for the input. Good to know SESSION_COOKIE_SAMESITE = None 
and CSRF_COOKIE_SAMESITE = None solved the issue 29975. Do you want to post 
there this solution? I can do it to.
I've updated safari-samesite-cookie-issue 
 to better 
reproduce the session issue too.

Florian, I didn't know about Safari Technology Preview, thanks! Installed 
it in my Mac Mojave 10.14.3. Tested again 
my safari-samesite-cookie-issue project. Issue seems solved.
My Safari is "Release 77 (Safari 12.2, WebKit 14608.1.7.3)".

Good to know it's a matter of time until this issue is solved in the wild. 
But I still think it's a serious problem: it caused us a major disruption 
in production because our transactions are very email-based, and therefore 
rely on third-party redirects.

What are the next steps?
A warning at the docs for these settings?
Happy to help if necessary.

On Monday, March 18, 2019 at 2:38:13 PM UTC-3, Mat Gadd wrote:
>
> You're correct that is how they rewrite the URLs, but I did know that and 
> expect that to be the case. 
>
> > On 18 Mar 2019, at 17:35, René Fleschenberg  > wrote: 
> > 
> > Hi. 
> > 
> > On 3/18/19 12:26 PM, Mat Gadd wrote: 
> >> Weirdly, it appears that Gmail isn't inserting click tracking for the 
> >> plain password reset link, but when I use my own URL shortener, I can 
> >> also see the google.com  redirect in play. It may 
> >> just be dev tools behaving strangely, or perhaps Google have tried to 
> >> avoid adding their tracker for password reset links. Who knows! 
> > 
> > I did not take the time to analyze this as thoroughly as I should have, 
> > but from a cursory look, it seemed to me that Gmail rewrites the links 
> > using Javascript, and only when you click on them. Could that explain 
> > why your observations? 
> > 
> > -- 
> > René 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers  (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0e45692d-1974-25ff-c938-f4770f8ee786%40fleschenberg.net.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76e3cf08-2c4c-4690-84e7-38eed0abb773%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

Hi Florian, thanks for your response.

> So this is a Safari bug?

Yes. Lax doesn't work as intended in Safari 12. Bug was confirmed here: 
https://bugs.webkit.org/show_bug.cgi?id=188165#c37 (comment 37)
Apple also says the newest beta versions of iOS/Mac should fix the 
issue: https://bugs.webkit.org/show_bug.cgi?id=188165#c43 (comment 43)
I didn't test this yet. Current stable version is still broken, I've 
confirmed yesterday.

> shouldn't httponly yes/no control whether JS can read the data?

Yes. But, on Django, the default is httponly false for CSRF cookie.
So even without httponly, Safari doesn't allow JS to read the CSRF cookie. 
Safari also doesn't send the session cookie nor the CSRF cookie during the 
request (if it comes from a cross-site source, like an email tracker 
redirection). 
You can reproduce with this Django 
code: https://github.com/vintasoftware/safari-samesite-cookie-issue 

> sadly I do not own a Mac

If you wish, I can provide you a BrowserStack account, so you can test on 
Safari from your browser.
Please reach me at flavio at vinta.com.br and I'll send you the credentials.

> I am wondering if this also results in 
https://code.djangoproject.com/ticket/29975 
<https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29975&sa=D&sntz=1&usg=AFQjCNEkFAWxojtNdyt0yDj-iwN3fHzv9g>
 or 
if this is just a result of their tracking protection

Yes, I think it's the same problem. I don't think this is a result of the 
"Protection Against First Party Bounce Trackers" because the issue don't 
happens if SESSION_COOKIE_SAMESITE = None and CSRF_COOKIE_SAMESITE = None, 
which is the behavior of Django < 2.1.
This is an issue with Django 2.1 defaults + Safari 12 + cross-site 
redirection.
That's why I suggested a change on defaults, or at least some clear warning.

Happy to answer more questions or to help any core developer to reproduce 
the issue.

Cheers,
Flávio.

On Friday, March 15, 2019 at 7:09:51 AM UTC-3, Florian Apolloner wrote:
>
> I am wondering if this also results in 
> https://code.djangoproject.com/ticket/29975 
> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29975&sa=D&sntz=1&usg=AFQjCNEkFAWxojtNdyt0yDj-iwN3fHzv9g>
>  
> or if this is just a result of their tracking protection. All in all it 
> would be great to know what Safari actually does… (sadly I do not own a Mac 
> :/) I'll dig through #30250 soon. 
>
> > - User will not be logged in if SESSION_COOKIE_SAMESITE = 'Lax'. That 
> behavior is only expected if 'Strict', AFAIK.
>
> So this is a Safari bug?
>
> > - User will not be able to make AJAX POST requests if 
> CSRF_COOKIE_SAMESITE = 'Lax', because JS code won't be able to read the 
> CSRF cookie.
>
> I have to reread the specs, but shouldn't httponly yes/no control whether 
> JS can read the data?
>
> Cheers,
> Florian
>
> On Wednesday, March 13, 2019 at 9:48:07 PM UTC+1, Flávio Junior wrote:
>>
>> Hi folks,
>> after upgrading to Django 2.1, we noticed many occurrences of 403 CSRF 
>> errors for Safari 12 users.
>> After days debugging the problem, we've pinpointed the issue to the 
>> Webkit Bug 188165: https://bugs.webkit.org/show_bug.cgi?id=188165
>>
>> In simple terms, Safari 12 implementation of samesite=Lax cookies is 
>> wrong.
>> It causes issues in many common request flows, like the OpenIdConnect 
>> flow for ASP.NET Core 2.1.
>>
>> For Django, the issue might be considered even worse. If the user comes 
>> from a cross-site redirection (like a tracker link from an email provider), 
>> Safari doesn't send samesite=lax cookies on the request. This causes 
>> multiple issues. We've been able to identify those three, but maybe there 
>> are more:
>> - User will not be logged in if SESSION_COOKIE_SAMESITE = 'Lax'. That 
>> behavior is only expected if 'Strict', AFAIK.
>> - User will not be able to make AJAX POST requests if 
>> CSRF_COOKIE_SAMESITE = 'Lax', because JS code won't be able to read the 
>> CSRF cookie.
>> - POSTs on other open tabs/windows will fail if CSRF_COOKIE_SAMESITE = 
>> 'Lax', because Safari triggered a CSRF cookie update after the first 
>> request without cookies.
>>
>> Those issues do not happen on Chrome, nor Firefox.
>> Full Django project example of the problem above is available here: ​
>> https://github.com/vintasoftware/safari-samesite-cookie-issue
>>
>> Since Safari 12 is the current stable version and it's widely deployed on 
>> iOS devices, I believe the Django default for CSRF_COO

Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

Hi folks,
after upgrading to Django 2.1, we noticed many occurrences of 403 CSRF 
errors for Safari 12 users.
After days debugging the problem, we've pinpointed the issue to the Webkit 
Bug 188165: https://bugs.webkit.org/show_bug.cgi?id=188165

In simple terms, Safari 12 implementation of samesite=Lax cookies is wrong.
It causes issues in many common request flows, like the OpenIdConnect flow 
for ASP.NET Core 2.1.

For Django, the issue might be considered even worse. If the user comes 
from a cross-site redirection (like a tracker link from an email provider), 
Safari doesn't send samesite=lax cookies on the request. This causes 
multiple issues. We've been able to identify those three, but maybe there 
are more:
- User will not be logged in if SESSION_COOKIE_SAMESITE = 'Lax'. That 
behavior is only expected if 'Strict', AFAIK.
- User will not be able to make AJAX POST requests if CSRF_COOKIE_SAMESITE 
= 'Lax', because JS code won't be able to read the CSRF cookie.
- POSTs on other open tabs/windows will fail if CSRF_COOKIE_SAMESITE = 
'Lax', because Safari triggered a CSRF cookie update after the first 
request without cookies.

Those issues do not happen on Chrome, nor Firefox.
Full Django project example of the problem above is available here: 
​https://github.com/vintasoftware/safari-samesite-cookie-issue

Since Safari 12 is the current stable version and it's widely deployed on 
iOS devices, I believe the Django default for CSRF_COOKIE_SAMESITE and 
SESSION_COOKIE_SAMESITE should be None, not Lax.

Upgrading to Django 2.1 caused this issue to us and frustrated many users. 
I think a more conservative default is necessary here to avoid breaking 
common use cases like visiting a web app page logged in after receiving a 
transactional or scheduled email.
If you do not wish to change the defaults, IMHO at least a warning should 
be placed on the documentation. For comparison, Microsoft issued a security 
advisory describing the bug on 
ASP.NET: https://github.com/aspnet/Announcements/issues/318
Please let me know your thoughts, I can help with a PR if needed.

Related Django ticket: https://code.djangoproject.com/ticket/30250

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0911f7b-f4e9-466b-bb72-ede732a5a41a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

After two years, made a PR for this during PyCon 
sprints: https://github.com/django/django/pull/8546 🍾
Em sábado, 5 de dezembro de 2015 04:31:12 UTC-8, Collin Anderson escreveu:
>
> Basically, the origin check would only be useful for safari (in this 
> case). Everywhere else we'd still need to rely on the referrer header.
>
> On Sat, Dec 5, 2015 at 3:42 AM, Florian Apolloner  > wrote:
>
>>
>>
>> On Friday, December 4, 2015 at 8:03:45 PM UTC+1, Flávio Junior wrote:
>>>
>>> I can create a ticket suggesting Django to check Origin header before 
>>> checking Referer. Or do you want to create that Collin?
>>>
>>
>> I think Firxfox does not send the origin header ever yet, do you have any 
>> docs on that (Aside from CORS with Ajax from the looks of it)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1cb9d411-8247-4e93-8120-5d043869c001%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/1cb9d411-8247-4e93-8120-5d043869c001%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f4046f53-3802-41eb-a903-60e5dcc8809f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Yes Jon, makes sense, sorry for missing that.
The only HTML-only solution I see for this is to manually 
add rel="noreferrer" to all external links on my webapp, which is a pain.
With extra backend code, one might also implement something similar 
to https://anon.click/ to prevent referrer leaking.

So the problem with Django strict referrer check is deeper. It introduces 
complexity to make secure webapps that don't leak referrer info.

PS: don't know if anon.click is safe or trustable.

Em sexta-feira, 4 de dezembro de 2015 16:52:26 UTC-3, Jon Dufresne escreveu:
>
> On Wed, Dec 2, 2015 at 10:29 AM, Flávio Junior  > wrote: 
> > Also, I can't imagine now why, but some 
> > developer might want to disable referer header altogether, and can 
> easily do 
> > so by setting policy to No Referrer. 
>
> Why is it unimaginable that I may want to maximize privacy for my 
> users? The domain my users are coming from is between me and my users. 
> If CSRF would work securely without any referer header (and not leak 
> the same data some other way), I would choose to disable it entirely. 
> Often the domain is enough to leak what kind of data a user was 
> reading or interacting with. For example, what might one assume 
> (rightly or wrongly) if the referer header was 
> "https://wikileaks.org";? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a8cc4a7-76c6-434a-8ccb-f6d043638d34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Hi Collin,
Firefox doesn't include Origin header on same-origin POST/PUT/DELETE 
requests. I just tested it and this SO answer says the same 
<http://stackoverflow.com/a/15514049/145349>.
But yes, checking both Origin and Referer headers would help giving 
support Origin When Cross-Origin.

I can create a ticket suggesting Django to check Origin header before 
checking Referer. Or do you want to create that Collin?

Em sexta-feira, 4 de dezembro de 2015 14:54:36 UTC-3, Collin Anderson 
escreveu:
>
> Also, if we checked the origin header, would it allow us to at least 
> support the "Origin When Cross-Origin" policy in all browsers? (Use the 
> Origin header for Safari and the referrer for all of the other browsers?)
>
>
> On Fri, Dec 4, 2015 at 10:38 AM, Tim Graham  > wrote:
>
>> Flávio, thanks -- since you seem to have a good understanding of the 
>> limitation, could you submit a documentation patch (or even just provide 
>> some draft text here)?
>>
>> On Friday, December 4, 2015 at 8:25:35 AM UTC-5, Flávio Junior wrote:
>>>
>>> Found a issue that already discusses this: 
>>> https://code.djangoproject.com/ticket/16870#comment:10
>>>
>>> Em quinta-feira, 3 de dezembro de 2015 13:41:09 UTC-3, Flávio Junior 
>>> escreveu:
>>>>
>>>> Florian, then Django will have to keep this limitation: can't use a 
>>>> global no-referrer policy on HTTPS because of strict referrer check. 
>>>> Correct? Should I create an issue to keep this logged?
>>>>
>>>> Em quinta-feira, 3 de dezembro de 2015 13:19:38 UTC-3, Florian 
>>>> Apolloner escreveu:
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior 
>>>>> wrote:
>>>>>>
>>>>>> If Django still needs 
>>>>>> <https://code.djangoproject.com/ticket/17563#comment:2> the strict 
>>>>>> referrer check, maybe a better error message should be implemented.
>>>>>>
>>>>>
>>>>> I do not see any reason why it would not need it anymore. Django needs 
>>>>> to ensure that the request came from a "trusted origin", therefore we 
>>>>> still 
>>>>> need it.
>>>>>
>>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c0ce17a5-3f0e-4218-a2c8-cecf7da07fb9%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/c0ce17a5-3f0e-4218-a2c8-cecf7da07fb9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f7b5a6e-0096-47ad-ad61-373a2d183c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Found a issue that already discusses 
this: https://code.djangoproject.com/ticket/16870#comment:10

Em quinta-feira, 3 de dezembro de 2015 13:41:09 UTC-3, Flávio Junior 
escreveu:
>
> Florian, then Django will have to keep this limitation: can't use a global 
> no-referrer policy on HTTPS because of strict referrer check. Correct? 
> Should I create an issue to keep this logged?
>
> Em quinta-feira, 3 de dezembro de 2015 13:19:38 UTC-3, Florian Apolloner 
> escreveu:
>>
>>
>>
>> On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior wrote:
>>>
>>> If Django still needs 
>>> <https://code.djangoproject.com/ticket/17563#comment:2> the strict 
>>> referrer check, maybe a better error message should be implemented.
>>>
>>
>> I do not see any reason why it would not need it anymore. Django needs to 
>> ensure that the request came from a "trusted origin", therefore we still 
>> need it.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/066ea758-b623-4292-bc26-79ba4878f63d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Florian, then Django will have to keep this limitation: can't use a global 
no-referrer policy on HTTPS because of strict referrer check. Correct? 
Should I create an issue to keep this logged?

Em quinta-feira, 3 de dezembro de 2015 13:19:38 UTC-3, Florian Apolloner 
escreveu:
>
>
>
> On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior wrote:
>>
>> If Django still needs 
>> <https://code.djangoproject.com/ticket/17563#comment:2> the strict 
>> referrer check, maybe a better error message should be implemented.
>>
>
> I do not see any reason why it would not need it anymore. Django needs to 
> ensure that the request came from a "trusted origin", therefore we still 
> need it.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfbe3a2a-a20f-4691-8eb9-9306bf178a6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

That won't solve the problem.
If you set policy to *No Referrer* and make a request to the same origin, 
Chrome sets Origin to "null", Firefox doesn't set the header and Safari 
sets the correct origin.

Em quarta-feira, 2 de dezembro de 2015 16:01:51 UTC-3, Collin Anderson 
escreveu:
>
> Seems to me we could ignore the referrer if we get a valid same-domain 
> Origin header.
>
> On Wed, Dec 2, 2015 at 1:29 PM, Flávio Junior  > wrote:
>
>> Some browsers already implement the Referrer Policy draft 
>> <https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-delivery>, 
>> which gives the developer more control over the referer HTTP header sent by 
>> the browser. Sometimes is useful to set a more private policy, like *Origin 
>> When Cross-Origin*, to prevent disclosing sensitive URL info to a 
>> third-party, like a password reset token for example.
>>
>> But one can't just set the policy to *Origin When Cross-Origin*, because 
>> it will break on Safari, since Safari doesn't adhere to newest spec and 
>> defaults to no-referrer, which breaks form submits on HTTPS because of 
>> Django strict referrer check. Also, I can't imagine now why, but some 
>> developer might want to disable referer header altogether, and can easily 
>> do so by setting policy to *No Referrer*. See the rationale 
>> <https://code.djangoproject.com/wiki/CsrfProtection#StrictRefererchecking> 
>> behind strict referrer check and the code 
>> <https://github.com/django/django/blob/master/django/middleware/csrf.py#L136-L158>
>> .
>>
>> Maybe Django shouldn't do do strict referrer check anymore?
>> It's very strange to change a HTML meta tag and break everything. And 
>> break in staging specifically, because this happens only on secure requests.
>>
>> If Django still needs 
>> <https://code.djangoproject.com/ticket/17563#comment:2> the strict 
>> referrer check, maybe a better error message should be implemented.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55a87572-3459-481b-8749-9ebc562c4f66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Some browsers already implement the Referrer Policy draft 
, 
which gives the developer more control over the referer HTTP header sent by 
the browser. Sometimes is useful to set a more private policy, like *Origin 
When Cross-Origin*, to prevent disclosing sensitive URL info to a 
third-party, like a password reset token for example.

But one can't just set the policy to *Origin When Cross-Origin*, because it 
will break on Safari, since Safari doesn't adhere to newest spec and 
defaults to no-referrer, which breaks form submits on HTTPS because of 
Django strict referrer check. Also, I can't imagine now why, but some 
developer might want to disable referer header altogether, and can easily 
do so by setting policy to *No Referrer*. See the rationale 
 
behind strict referrer check and the code 

.

Maybe Django shouldn't do do strict referrer check anymore?
It's very strange to change a HTML meta tag and break everything. And break 
in staging specifically, because this happens only on secure requests.

If Django still needs 
 the strict referrer 
check, maybe a better error message should be implemented.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.