CSRF context processor never sets NOTPROVIDED

[Nick Sandford]

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?

[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.

[Nick Sandford]

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.

[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?

[Tim Graham]

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!