From a5b44ed873e4a12eb958033859a52af43f691f85 Mon Sep 17 00:00:00 2001
From: Carl Meyer <carl@oddbird.net>
Date: Fri, 10 Jun 2011 16:19:56 +0000
Subject: [PATCH] [1.3.X] 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.

Backport of r16361 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.3.X@16362 bcc190cf-cafb-0310-a4f2-bffc1f526a37
---
 docs/ref/contrib/csrf.txt | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index f3b95a11d3..4edccdd398 100644
--- a/docs/ref/contrib/csrf.txt
+++ b/docs/ref/contrib/csrf.txt
@@ -408,15 +408,16 @@ middleware if it is used as instructed (``UpdateCacheMiddleware`` goes before
 all other 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
-that will require a CSRF token to be inserted you should use the
-:func:`django.views.decorators.vary.vary_on_cookie` decorator first::
+will not yet have been able to set the Vary header or the CSRF cookie, and the
+response will be cached without either one. In this case, on any views that
+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.vary import vary_on_cookie
+  from django.views.decorators.csrf import csrf_protect
 
   @cache_page(60 * 15)
-  @vary_on_cookie
+  @csrf_protect
   def my_view(request):
       # ...