Refs #15855 -- Recommended the csrf_protect decorator rather than vary_on_cookie as workaround for cache_page caching the response before it gets to middleware.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16361 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Carl Meyer 2011-06-10 16:18:40 +00:00
parent 528157ce73
commit 0e03a504bf
1 changed files with 6 additions and 5 deletions

View File

@ -238,15 +238,16 @@ middleware will play well with the cache middleware if it is used as instructed
(``UpdateCacheMiddleware`` goes before all other middleware). (``UpdateCacheMiddleware`` goes before all other middleware).
However, if you use cache decorators on individual views, the CSRF middleware However, if you use cache decorators on individual views, the CSRF middleware
will not yet have been able to set the Vary header. In this case, on any views will not yet have been able to set the Vary header or the CSRF cookie, and the
that will require a CSRF token to be inserted you should use the response will be cached without either one. In this case, on any views that
:func:`django.views.decorators.vary.vary_on_cookie` decorator first:: will require a CSRF token to be inserted you should use the
:func:`django.views.decorators.csrf.csrf_protect` decorator first::
from django.views.decorators.cache import cache_page from django.views.decorators.cache import cache_page
from django.views.decorators.vary import vary_on_cookie from django.views.decorators.csrf import csrf_protect
@cache_page(60 * 15) @cache_page(60 * 15)
@vary_on_cookie @csrf_protect
def my_view(request): def my_view(request):
# ... # ...