Fixed #26628 -- Changed CSRF logger to django.security.csrf.

docs/ref/csrf.txt

@@ -192,6 +192,8 @@ both is fine, and will incur minimal overhead.
     If you are using class-based views, you can refer to
     :ref:`Decorating class-based views<decorating-class-based-views>`.
 
+.. _csrf-rejected-requests:
+
 Rejected requests
 =================
 
@@ -205,8 +207,13 @@ The error page, however, is not very friendly, so you may want to provide your
 own view for handling this condition.  To do this, simply set the
 :setting:`CSRF_FAILURE_VIEW` setting.
 
-CSRF failures are logged as warnings to the :ref:`django-request-logger`
-logger.
+CSRF failures are logged as warnings to the :ref:`django.security.csrf
+<django-security-logger>` logger.
+
+.. versionchanged:: 1.11
+
+    In older versions, CSRF failures are logged to the ``django.request``
+    logger.
 
 .. _how-csrf-works:
 

docs/releases/1.11.txt

@@ -246,6 +246,9 @@ Miscellaneous
 
 * Support for SpatiaLite < 4.0 is dropped.
 
+* CSRF failures are logged to the ``django.security.csrf ``` logger instead of
+  ``django.request``.
+
 .. _deprecated-features-1.11:
 
 Features deprecated in 1.11

docs/topics/logging.txt

@@ -532,20 +532,23 @@ This logging does not include framework-level initialization (e.g.
 ``COMMIT``, and ``ROLLBACK``). Turn on query logging in your database if you
 wish to view all database queries.
 
+.. _django-security-logger:
+
 ``django.security.*``
 ~~~~~~~~~~~~~~~~~~~~~~
 
 The security loggers will receive messages on any occurrence of
-:exc:`~django.core.exceptions.SuspiciousOperation`. There is a sub-logger for
-each sub-type of SuspiciousOperation. The level of the log event depends on
-where the exception is handled.  Most occurrences are logged as a warning, while
+:exc:`~django.core.exceptions.SuspiciousOperation` and other security-related
+errors. There is a sub-logger for each subtype of security error, including all
+``SuspiciousOperation``\s. The level of the log event depends on where the
+exception is handled.  Most occurrences are logged as a warning, while
 any ``SuspiciousOperation`` that reaches the WSGI handler will be logged as an
 error. For example, when an HTTP ``Host`` header is included in a request from
 a client that does not match :setting:`ALLOWED_HOSTS`, Django will return a 400
 response, and an error message will be logged to the
 ``django.security.DisallowedHost`` logger.
 
-These log events will reach the 'django' logger by default, which mails error
+These log events will reach the ``django`` logger by default, which mails error
 events to admins when ``DEBUG=False``. Requests resulting in a 400 response due
 to a ``SuspiciousOperation`` will not be logged to the ``django.request``
 logger, but only to the ``django.security`` logger.
@@ -567,6 +570,10 @@ specific logger following this example:
         },
     },
 
+Other ``django.security`` loggers not based on ``SuspiciousOperation`` are:
+
+* ``django.security.csrf``: For :ref:`CSRF failures <csrf-rejected-requests>`.
+
 ``django.db.backends.schema``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~