csrf_token tag is empty on Resolver404 error

[SardarNL]

The tag {% csrf_token %} prints context.csrf_token, which is set by default django.core.context_processors.csrf, which uses django.middleware.csrf.get_token(), which looks in request.META['CSRF_COOKIE'] , which is set by CsrfViewMiddleware.process_view(). So if process_view() isn't called, then there will be no META['CSRF_COOKIE'], then {% csrf_token %} would print nothing.

Lets look now at django.core.handlers.BaseHandler.get_response(). It first calls all process_request(), then resolves the view and *then* calls all process_view(). So, if none of your URL patterns match, then your CsrfViewMiddleware.process_view() will not be called. Resolver404 exception is http.Http404, so if no view is found, the handler will use resolver.resolve404() view to serve 404 page.

The problem: 404 page uses {% csrf_token %} to render a POST form to search view. It works if URL is matched by a view, but the view itself raises Http404. It doesn't work if URL is not matched by any pattern.

Solution:

1) refactor CsrfViewMiddleware.process_view(), move setting request.META['CSRF_COOKIE'] to a separate _method()
2) call this method for resolver.resolve404() view or in get_token()

Possible problems: browser may ignore cookies set by 404 page.

Workaround: search page is using csrf_exempt at this moment.

Severity: minor

[Russell Keith-Magee]

Context processors are not executed on error pages, so the csrf_token, and any other context request variables, aren't available. This is by design -- when errors occur, you don't want another error to be raised when showing the error page, and since context could be the cause of the error, the error pages aren't formed using a RequestContext.