Reverted 10094 and 10095 (in favour of solution that will hopefully land for beta 2)

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

django/conf/global_settings.py

@@ -301,12 +301,10 @@ 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,8 +59,6 @@ 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,47 +7,46 @@ Cross Site Request Forgery protection
 .. module:: django.contrib.csrf
    :synopsis: Protects against Cross Site Request Forgeries
 
-The CsrfMiddleware classes provides easy-to-use protection against
+The CsrfMiddleware class provides easy-to-use protection against
-`Cross Site Request Forgeries`_.  This type of attack occurs when a
+`Cross Site Request Forgeries`_.  This type of attack occurs when a malicious
-malicious Web site creates a link or form button that is intended to
+Web site creates a link or form button that is intended to perform some action
-perform some action on your Web site, using the credentials of a
+on your Web site, using the credentials of a logged-in user who is tricked
-logged-in user who is tricked into clicking on the link in their
+into clicking on the link in their browser.
-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
+are side-effect free.  POST requests can then be protected by adding this
-these middleware into your list of installed middleware.
+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
+Add the middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'`` to
-``'django.contrib.csrf.middleware.CsrfViewMiddleware'`` and
+your list of middleware classes, :setting:`MIDDLEWARE_CLASSES`. It needs to process
-``'django.contrib.csrf.middleware.CsrfResponseMiddleware'`` to your
+the response after the SessionMiddleware, so must come before it in the
-list of middleware classes,
+list. It also must process the response before things like compression
-:setting:`MIDDLEWARE_CLASSES`. ``CsrfResponseMiddleware`` needs to
+happen to the response, so it must come after GZipMiddleware in the
-process the response after the ``SessionMiddleware``, so must come
+list.
-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, which combines the two classes, is also
+The ``CsrfMiddleware`` class is actually composed of two middleware:
-available, for backwards compatibility with Django 1.0.
+``CsrfViewMiddleware`` which performs the checks on incoming requests,
+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 either of
+To manually exclude a view function from being handled by the
-the two CSRF middleware, you can use the ``csrf_exempt`` decorator,
+CsrfMiddleware, you can use the ``csrf_exempt`` decorator, found in
-found in the ``django.contrib.csrf.middleware`` module. For example::
+the ``django.contrib.csrf.middleware`` module. For example::
 
     from django.contrib.csrf.middleware import csrf_exempt
 
@@ -55,12 +54,12 @@ found in the ``django.contrib.csrf.middleware`` module. For example::
         return HttpResponse('Hello world')
     my_view = csrf_exempt(my_view)
 
-Like the middleware, the ``csrf_exempt`` decorator is composed of two
+Like the middleware itself, the ``csrf_exempt`` decorator is composed
-parts: a ``csrf_view_exempt`` decorator and a ``csrf_response_exempt``
+of two parts: a ``csrf_view_exempt`` decorator and a
-decorator, found in the same module.  These disable the view
+``csrf_response_exempt`` decorator, found in the same module.  These
-protection mechanism (``CsrfViewMiddleware``) and the response
+disable the view protection mechanism (``CsrfViewMiddleware``) and the
-post-processing (``CsrfResponseMiddleware``) respectively.  They can
+response post-processing (``CsrfResponseMiddleware``) respectively.
-be used individually if required.
+They can 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
@@ -69,7 +68,7 @@ exempt. (See the next section.)
 How it works
 ============
 
-The CSRF middleware do two things:
+CsrfMiddleware does 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
@@ -113,9 +112,9 @@ don't trust content within the same domain or subdomains.)
 Limitations
 ===========
 
-These middleware require Django's session framework to work. If you
+CsrfMiddleware requires Django's session framework to work. If you have
-have a custom authentication system that manually sets cookies and the
+a custom authentication system that manually sets cookies and the like,
-like, it won't help you.
+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/ref/settings.txt

@@ -760,11 +760,10 @@ MIDDLEWARE_CLASSES
 
 Default::
 
-    ("django.contrib.csrf.middleware.CsrfViewMiddleware",
+    ("django.contrib.sessions.middleware.SessionMiddleware",
-     "django.contrib.csrf.middleware.CsrfResponseMiddleware",
-     "django.contrib.sessions.middleware.SessionMiddleware",
      "django.contrib.auth.middleware.AuthenticationMiddleware",
-     "django.middleware.common.CommonMiddleware")
+     "django.middleware.common.CommonMiddleware",
+     "django.middleware.doc.XViewMiddleware")
 
 A tuple of middleware classes to use. See :ref:`topics-http-middleware`.
 

docs/topics/http/middleware.txt

@@ -28,10 +28,9 @@ created by :djadmin:`django-admin.py startproject <startproject>`::
 
     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',
+        'django.middleware.doc.XViewMiddleware',
     )
 
 During the request phases (:meth:`process_request` and :meth:`process_view`