Added CSRF middleware to default settings and updated docs.

Updated docs to reflect the change, and the fact that using the
two separate middleware is preferred to using the combined one.



git-svn-id: http://code.djangoproject.com/svn/django/trunk@10094 bcc190cf-cafb-0310-a4f2-bffc1f526a37

django/conf/global_settings.py

@@ -301,10 +301,12 @@ DEFAULT_INDEX_TABLESPACE = ''
 # this middleware classes will be applied in the order given, and in the
 # response phase the middleware will be applied in reverse order.
 MIDDLEWARE_CLASSES = (
+#     'django.middleware.gzip.GZipMiddleware',
+    'django.contrib.csrf.middleware.CsrfViewMiddleware',
+    'django.contrib.csrf.middleware.CsrfResponseMiddleware',
     'django.contrib.sessions.middleware.SessionMiddleware',
     'django.contrib.auth.middleware.AuthenticationMiddleware',
 #     'django.middleware.http.ConditionalGetMiddleware',
-#     'django.middleware.gzip.GZipMiddleware',
     'django.middleware.common.CommonMiddleware',
 )
 

django/conf/project_template/settings.py

@@ -59,6 +59,8 @@ TEMPLATE_LOADERS = (
 
 MIDDLEWARE_CLASSES = (
     'django.middleware.common.CommonMiddleware',
+    'django.contrib.csrf.middleware.CsrfViewMiddleware',
+    'django.contrib.csrf.middleware.CsrfResponseMiddleware',
     'django.contrib.sessions.middleware.SessionMiddleware',
     'django.contrib.auth.middleware.AuthenticationMiddleware',
 )

docs/ref/contrib/csrf.txt

@@ -7,46 +7,47 @@ Cross Site Request Forgery protection
 .. module:: django.contrib.csrf
    :synopsis: Protects against Cross Site Request Forgeries
 
-The CsrfMiddleware class provides easy-to-use protection against
+The CsrfMiddleware classes provides easy-to-use protection against
-`Cross Site Request Forgeries`_.  This type of attack occurs when a malicious
+`Cross Site Request Forgeries`_.  This type of attack occurs when a
-Web site creates a link or form button that is intended to perform some action
+malicious Web site creates a link or form button that is intended to
-on your Web site, using the credentials of a logged-in user who is tricked
+perform some action on your Web site, using the credentials of a
-into clicking on the link in their browser.
+logged-in user who is tricked into clicking on the link in their
+browser.
 
 The first defense against CSRF attacks is to ensure that GET requests
-are side-effect free.  POST requests can then be protected by adding this
+are side-effect free.  POST requests can then be protected by adding
-middleware into your list of installed middleware.
+these middleware into your list of installed middleware.
 
 .. _Cross Site Request Forgeries: http://www.squarefree.com/securitytips/web-developers.html#CSRF
 
 How to use it
 =============
 
-Add the middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'`` to
+Add the middleware
-your list of middleware classes, :setting:`MIDDLEWARE_CLASSES`. It needs to process
+``'django.contrib.csrf.middleware.CsrfViewMiddleware'`` and
-the response after the SessionMiddleware, so must come before it in the
+``'django.contrib.csrf.middleware.CsrfResponseMiddleware'`` to your
-list. It also must process the response before things like compression
+list of middleware classes,
-happen to the response, so it must come after GZipMiddleware in the
+:setting:`MIDDLEWARE_CLASSES`. ``CsrfResponseMiddleware`` needs to
-list.
+process the response after the ``SessionMiddleware``, so must come
+before it in the list.  It also must process the response before
+things like compression happen to the response, so it must come after
+``GZipMiddleware`` in the list.
 
-The ``CsrfMiddleware`` class is actually composed of two middleware:
+The ``CsrfMiddleware`` class, which combines the two classes, is also
-``CsrfViewMiddleware`` which performs the checks on incoming requests,
+available, for backwards compatibility with Django 1.0.
-and ``CsrfResponseMiddleware`` which performs post-processing of the
-result.  This allows the individual components to be used and/or
-replaced instead of using ``CsrfMiddleware``.
 
 .. versionchanged:: 1.1
-    (previous versions of Django did not provide these two components
+    previous versions of Django did not provide these two components
-    of ``CsrfMiddleware`` as described above)
+    of ``CsrfMiddleware`` as described above.
 
 Exceptions
 ----------
 
 .. versionadded:: 1.1
 
-To manually exclude a view function from being handled by the
+To manually exclude a view function from being handled by either of
-CsrfMiddleware, you can use the ``csrf_exempt`` decorator, found in
+the two CSRF middleware, you can use the ``csrf_exempt`` decorator,
-the ``django.contrib.csrf.middleware`` module. For example::
+found in the ``django.contrib.csrf.middleware`` module. For example::
 
     from django.contrib.csrf.middleware import csrf_exempt
 
@@ -54,12 +55,12 @@ the ``django.contrib.csrf.middleware`` module. For example::
         return HttpResponse('Hello world')
     my_view = csrf_exempt(my_view)
 
-Like the middleware itself, the ``csrf_exempt`` decorator is composed
+Like the middleware, the ``csrf_exempt`` decorator is composed of two
-of two parts: a ``csrf_view_exempt`` decorator and a
+parts: a ``csrf_view_exempt`` decorator and a ``csrf_response_exempt``
-``csrf_response_exempt`` decorator, found in the same module.  These
+decorator, found in the same module.  These disable the view
-disable the view protection mechanism (``CsrfViewMiddleware``) and the
+protection mechanism (``CsrfViewMiddleware``) and the response
-response post-processing (``CsrfResponseMiddleware``) respectively.
+post-processing (``CsrfResponseMiddleware``) respectively.  They can
-They can be used individually if required.
+be used individually if required.
 
 You don't have to worry about doing this for most AJAX views. Any
 request sent with "X-Requested-With: XMLHttpRequest" is automatically
@@ -68,7 +69,7 @@ exempt. (See the next section.)
 How it works
 ============
 
-CsrfMiddleware does two things:
+The CSRF middleware do two things:
 
 1. It modifies outgoing requests by adding a hidden form field to all
    'POST' forms, with the name 'csrfmiddlewaretoken' and a value which is
@@ -112,9 +113,9 @@ don't trust content within the same domain or subdomains.)
 Limitations
 ===========
 
-CsrfMiddleware requires Django's session framework to work. If you have
+These middleware require Django's session framework to work. If you
-a custom authentication system that manually sets cookies and the like,
+have a custom authentication system that manually sets cookies and the
-it won't help you.
+like, it won't help you.
 
 If your app creates HTML pages and forms in some unusual way, (e.g.
 it sends fragments of HTML in JavaScript document.write statements)

docs/releases/1.1-alpha-1.txt

@@ -74,7 +74,13 @@ Other new features and changes introduced since Django 1.0 include:
   ``CsrfMiddleware`` class (which does both) remains for
   backwards-compatibility, but using the split classes is now recommended in
   order to allow fine-grained control of when and where the CSRF processing
-  takes place.
+  takes place.  Decorators are provided for selectively turning it off for
+  certain views.
+
+  Also, these middleware are now enabled by default when creating new projects.
+  It is recommended to add these middleware, if not already present, to existing
+  projects, to provide protection for the admin (which has no other CSRF
+  protection) and other apps.
 
 * :func:`~django.core.urlresolvers.reverse` and code which uses it (e.g., the
   ``{% url %}`` template tag) now works with URLs in Django's administrative