#29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting
-----------------------------------+--------------------------------------
Reporter: Brenton Partridge | Owner: nobody
Type: New feature | Status: new
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: csrf, settings | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-----------------------------------+--------------------------------------
Description changed by Brenton Partridge:
Old description:
> https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-httponly
> says:
>
> "If you enable this and need to send the value of the CSRF token with an
> AJAX request, your JavaScript must pull the value from a hidden CSRF
> token form input on the page instead of from the cookie."
>
> However, the documentation at
> https://docs.djangoproject.com/en/dev/ref/csrf/#ajax makes no mention of
> this setting; it's only barely listed at the bottom of the page. And if
> HttpOnly is set, then the recommendation to read the token from the
> cookie will fail.
>
> Anyone inheriting a codebase, or using a boilerplate that defaults
> CSRF_COOKIE_HTTPONLY to True, might naturally read the CSRF AJAX page,
> not even realize they need to check CSRF_COOKIE_HTTPONLY, and run into
> issues where it's clear that the CSRF cookie is being set in the
> browser's storage, but isn't readable by `Cookies.get('csrftoken')`
> (which is recommended as the "canonical way to do things").
>
> If our standard is to include code about how to read cookies, we
> shouldn't assume that the reader would instantly know that this mismatch
> is due to HttpOnly.
>
> I'd propose modifying the preface and relevant headings on that page
> from:
>
> First, you must get the CSRF token. How to do that depends on whether or
> not the CSRF_USE_SESSIONS setting is enabled.
>
> Acquiring the token if CSRF_USE_SESSIONS is False/True
>
> to:
>
> First, you must get the CSRF token. How to do that depends on whether or
> not the CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY setting is enabled.
>
> Acquiring the token if CSRF_COOKIE_HTTPONLY and CSRF_USE_SESSIONS are
> False
>
> Acquiring the token if CSRF_COOKIE_HTTPONLY or CSRF_USE_SESSIONS is True
New description:
https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-httponly
says:
"If you enable this and need to send the value of the CSRF token with an
AJAX request, your JavaScript must pull the value from a hidden CSRF token
form input on the page instead of from the cookie."
However, the documentation at
https://docs.djangoproject.com/en/dev/ref/csrf/#ajax makes no mention of
this setting; it's only barely listed at the bottom of the page. And if
HttpOnly is set, then the recommendation to read the token from the cookie
will fail.
Anyone inheriting a codebase, or using a boilerplate that defaults
CSRF_COOKIE_HTTPONLY to True, might naturally read the CSRF AJAX page, not
even realize they need to check CSRF_COOKIE_HTTPONLY, and run into issues
where it's clear that the CSRF cookie is being set in the browser's
storage, but isn't readable by `Cookies.get('csrftoken')` (which is
recommended as the "canonical way to do things").
If our standard is to include code about how to read cookies, we shouldn't
assume that the reader would instantly know that this mismatch is due to
HttpOnly.
I'd propose modifying the preface and relevant headings on that page from:
{{{
First, you must get the CSRF token. How to do that depends on whether or
not the CSRF_USE_SESSIONS setting is enabled.
Acquiring the token if CSRF_USE_SESSIONS is False/True
}}}
to:
{{{
First, you must get the CSRF token. How to do that depends on whether or
not the CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY setting is enabled.
Acquiring the token if CSRF_COOKIE_HTTPONLY and CSRF_USE_SESSIONS are
False
Acquiring the token if CSRF_COOKIE_HTTPONLY or CSRF_USE_SESSIONS is True
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29879#comment:1>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.99b386ef831b4d6d3878dbb5c21d2cc3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
