[Django] #27470: CSRF context processor never sets NOTPROVIDED
Django
-----------------------------------------+------------------------
Reporter: Nick Sandford | Owner: nobody
Type: Uncategorized | Status: new
Component: CSRF | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-----------------------------------------+------------------------
The CSRF context processor expects `get_token` to return None when
CSRF_COOKIE is not in `request.META`. When this happens, it sets
`context['csrf_token']` to a sentinel value of NOTPROVIDED instead of
generating a new token.
This is a regression from 1.8.
1.8:
https://github.com/django/django/blob/stable/1.8.x/django/middleware/csrf.py#L51
1.10:
https://github.com/django/django/blob/stable/1.10.x/django/middleware/csrf.py#L94
This is a problem if the 404 handler is called from a URL that doesn't
exist. Since a view wasn't found, the CSRF middleware was never run and
any existing token won't be set on `request.META`. The new token will be
set by `get_token` and returned to the user, replacing the existing token.
If, say, a javascript bug or a different tab is causing the 404 handler to
be run after a page with a form is loaded, that form will no longer be
submittable.
Do we fix this, or remove the check for `None` in the context processor?
--
Ticket URL: <https://code.djangoproject.com/ticket/27470>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Nick Sandford | Owner: nobody
Type: Uncategorized | Status: new
Component: CSRF | Version: 1.10
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+--------------------------------------
Changes (by Tim Graham):
* cc: Shai Berger (added)
* easy: 1 => 0
Comment:
Did you bisect to find the commit where the behavior changed? I guess it's
probably 5112e65ef2df1dbb95ff83026b6a962fb2688661, Fixed #20869 -- made
CSRF tokens change every request by salt-encrypting them.
--
Ticket URL: <https://code.djangoproject.com/ticket/27470#comment:1>
Django
Reporter: Nick Sandford | Owner: nobody
Type: Uncategorized | Status: new
Component: CSRF | Version: 1.10
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+--------------------------------------
Comment (by Nick Sandford):
Replying to [comment:1 Tim Graham]:
> Did you bisect to find the commit where the behavior changed? I guess
it's probably 5112e65ef2df1dbb95ff83026b6a962fb2688661, Fixed #20869 --
made CSRF tokens change every request by salt-encrypting them.
Yeah, that looks like the commit that's caused the changed behaviour.
--
Ticket URL: <https://code.djangoproject.com/ticket/27470#comment:2>
Django
Reporter: Nick Sandford | Owner: nobody
Type: Uncategorized | Status: new
Component: CSRF | Version: 1.10
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+--------------------------------------
Comment (by Tim Graham):
Nick, could you give more specific steps to reproduce the issue? For
example, what does "if the 404 handler is called from a URL that doesn't
exist" look like?
--
Ticket URL: <https://code.djangoproject.com/ticket/27470#comment:3>
Django
Reporter: Nick Sandford | Owner: nobody
Component: CSRF | Version: 1.10
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+--------------------------------------
Changes (by Tim Graham):
* status: new => closed
* resolution: => needsinfo
Comment:
I loaded an admin change form in a tab, then I loaded a 404 page in a
second tab, then I submitted the form in the first tab and didn't
encounter a problem. Please reopen with more specific details about how to
reproduce the issue. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/27470#comment:4>