[2.2.x] Fixed #30091 -- Doc'd middleware ordering requirements with CSRF_USE_SESSIONS.

Backport of bae66e759f from master.

docs/ref/middleware.txt

@@ -426,6 +426,10 @@ Here are some hints about the ordering of various Django middleware classes:
 
 #. :class:`~django.contrib.sessions.middleware.SessionMiddleware`
 
+   Before any middleware that may raise an an exception to trigger an error
+   view (such as :exc:`~django.core.exceptions.PermissionDenied`) if you're
+   using :setting:`CSRF_USE_SESSIONS`.
+
    After ``UpdateCacheMiddleware``: Modifies ``Vary`` header.
 
 #. :class:`~django.middleware.http.ConditionalGetMiddleware`
@@ -450,13 +454,14 @@ Here are some hints about the ordering of various Django middleware classes:
    Close to the top: it redirects when :setting:`APPEND_SLASH` or
    :setting:`PREPEND_WWW` are set to ``True``.
 
+   After ``SessionMiddleware`` if you're using :setting:`CSRF_USE_SESSIONS`.
+
 #. :class:`~django.middleware.csrf.CsrfViewMiddleware`
 
    Before any view middleware that assumes that CSRF attacks have been dealt
    with.
 
-   It must come after ``SessionMiddleware`` if you're using
+   After ``SessionMiddleware`` if you're using :setting:`CSRF_USE_SESSIONS`.
-   :setting:`CSRF_USE_SESSIONS`.
 
 #. :class:`~django.contrib.auth.middleware.AuthenticationMiddleware`
 

docs/ref/settings.txt

@@ -405,6 +405,12 @@ Storing the CSRF token in a cookie (Django's default) is safe, but storing it
 in the session is common practice in other web frameworks and therefore
 sometimes demanded by security auditors.
 
+Since the :ref:`default error views <error-views>` require the CSRF token,
+:class:`~django.contrib.sessions.middleware.SessionMiddleware` must appear in
+:setting:`MIDDLEWARE` before any middleware that may raise an exception to
+trigger an error view (such as :exc:`~django.core.exceptions.PermissionDenied`)
+if you're using ``CSRF_USE_SESSIONS``. See :ref:`middleware-ordering`.
+
 .. setting:: CSRF_FAILURE_VIEW
 
 ``CSRF_FAILURE_VIEW``