Changes between Version 14 and Version 23 of Ticket #24496


Ignore:
Timestamp:
Sep 1, 2015, 11:01:29 AM (9 years ago)
Author:
Carl Meyer
Comment:

Resetting the title/summary of this ticket to again be specific to the CSRF_COOKIE_DOMAIN fix. Also resetting the "needs docs" flag, since I think that's all that the original PR for that (​https://github.com/django/django/pull/4337) is waiting on.

Sorry again for causing confusion and extra work by mixing these two slightly different issues together in one ticket.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #24496

    • Property Needs documentation set
    • Property Summary Check CSRF Referer against CSRF_TRUSTED_ORIGINS → Check CSRF Referer against CSRF_COOKIE_DOMAIN

  • Ticket #24496 – Description

    v14 v23  
    11Right now, if you try to share a CSRF token across a subdomain without https, everything works great since the Referer header isn't validated.
    22
    3 But over https, we want to be a bit more strict and make sure that the Referer is from another secure site, and also that the Referer matches where we think it should be coming from. Django should validate that the Referer header matches one of the domains listed in `CSRF_TRUSTED_ORIGINS`, including the currently responding `ALLOWED_HOST`.
     3But over https, we want to be a bit more strict and make sure that the Referer is from another secure site, and also that the Referer matches where we think it should be coming from. The canonical source for where we think it should be from is `CSRF_COOKIE_DOMAIN`.
     4
     5If we set our `CSRF_COOKIE_DOMAIN` to `.example.com`, that means our CSRF validation should work for `www.example.com` and `foo.example.com`. Not just strictly the domain the request is coming from.
Back to Top