#33529: Possibly Incorrect statement in the docs about CRSF tokens
------------------------------+--------------------------------------
Reporter: Michael | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 4.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by Michael):
Replying to [comment:6 Florian Apolloner]:
> Hi Michael,
>
> the CSRF token is POSTed but that does not mean it has to originate from
the DOM. The middleware operates on the HTTP level, all it sees is post
data, it has no concept of the DOM. That is why I ment I do not understand
what the note is (well was, this is fixed in the dev branch) trying to
say.
Hi Florian,
Thanks for this and the clarification of how the admin site handles it. I
didn't reply to the other points because I was reading up a bit, because I
think I don't understand the whole system and did not want to waste your
time. I have also been reading that diff, and I see it changes the text
from
The CSRF token is also present in the DOM, but only if explicitly
included
using `csrf_token` in a template. The cookie contains the canonical
token; the ``CsrfViewMiddleware`` will prefer the cookie to the token
in
the DOM. Regardless, you're guaranteed to have the cookie if the token
is
present in the DOM, so you should use the cookie!
to
The CSRF token is also present in the DOM in a masked form, but only
if
explicitly included using `csrf_token` in a template. The cookie
contains the canonical, unmasked token. The
:class:`~django.middleware.csrf.CsrfViewMiddleware` will accept
either.
However, in order to protect against `BREACH`_ attacks, it's
recommended to
use a masked token.
I am guessing the new behaviour is if the CSRF Middleware receives a
request that has the `X-CSRFToken` header, and a `csrftoken` key in the
POST data, it will prefer the POST data?
Maybe a note about how the CSRF Middleware verifies the token when :
`X-CSRFToken` header *and* the POST `csrftoken` entry are *both*
provided. This is a common scenario if one logs out and in another tab,
and uses JavaScript Ajax calls that can add both:
E.g.:
1. There is a POST `csrftoken` entry, the middleware tries it, and raises
CSRF exception, even those there is a valid `X-CSRFToken` header
Or:
1. There is a POST `csrftoken` entry, the middleware tries it, fails...
2. Check whether there is a `X-CSRFToken` header, it exists and passes,
request is okay
Or.
1. Tries `X-CSRFToken` header first it exists and passes, request is okay
--
Ticket URL: <https://code.djangoproject.com/ticket/33529#comment:7>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.87e9d2ec796c709af76aae5cb5fa5a59%40djangoproject.com.
