Opened 8 years ago

Closed 8 years ago

#27470 closed Uncategorized (needsinfo)

CSRF context processor never sets NOTPROVIDED

Reported by: Nick Sandford Owned by: nobody
Component: CSRF Version: 1.10
Severity: Normal Keywords:
Cc: Shai Berger Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?

Change History (4)

comment:1 by Tim Graham, 8 years ago

Cc: Shai Berger added
Easy pickings: unset

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.

in reply to:  1 comment:2 by Nick Sandford, 8 years ago

Replying to 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.

comment:3 by Tim Graham, 8 years ago

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?

comment:4 by Tim Graham, 8 years ago

Resolution: needsinfo
Status: newclosed

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!

Note: See TracTickets for help on using tickets.
Back to Top