1
0
mirror of https://github.com/django/django.git synced 2024-12-23 01:25:58 +00:00

Moved CSRF docs out of contrib.

This commit is contained in:
Thomas Chaumeny 2014-10-31 23:39:46 +01:00 committed by Tim Graham
parent d968bd5258
commit d3db878e4b
16 changed files with 24 additions and 32 deletions

View File

@ -227,7 +227,7 @@ applications and Django provides multiple protection tools and mechanisms:
* :doc:`Security overview <topics/security>`
* :doc:`Disclosed security issues in Django <releases/security>`
* :doc:`Clickjacking protection <ref/clickjacking>`
* :doc:`Cross Site Request Forgery protection <ref/contrib/csrf>`
* :doc:`Cross Site Request Forgery protection <ref/csrf>`
* :doc:`Cryptographic signing <topics/signing>`
* :ref:`Security Middleware <security-middleware>`

View File

@ -25,7 +25,6 @@ those packages have.
admin/index
auth
contenttypes
csrf
flatpages
formtools/index
gis/index
@ -63,13 +62,6 @@ Django model is a separate content type.
See the :doc:`contenttypes documentation </ref/contrib/contenttypes>`.
csrf
====
A middleware for preventing Cross Site Request Forgeries
See the :doc:`csrf documentation </ref/contrib/csrf>`.
flatpages
=========

View File

@ -26,15 +26,14 @@ below.
How to use it
=============
To enable CSRF protection for your views, follow these steps:
To take advantage of CSRF protection in your views, follow these steps:
1. Add the middleware
``'django.middleware.csrf.CsrfViewMiddleware'`` to your list of
middleware classes, :setting:`MIDDLEWARE_CLASSES`. (It should come
before any view middleware that assume that CSRF attacks have
been dealt with.)
1. The CSRF middleware is activated by default in the
:setting:`MIDDLEWARE_CLASSES` setting. If you override that setting, remember
that ``'django.middleware.csrf.CsrfViewMiddleware'`` should come before any
view middleware that assume that CSRF attacks have been dealt with.
Alternatively, you can use the decorator
If you disabled it, which is not recommended, you can use
:func:`~django.views.decorators.csrf.csrf_protect` on particular views
you want to protect (see below).

View File

@ -10,6 +10,7 @@ API Reference
class-based-views/index
clickjacking
contrib/index
csrf
databases
django-admin
exceptions

View File

@ -388,7 +388,7 @@ CSRF protection middleware
Adds protection against Cross Site Request Forgeries by adding hidden form
fields to POST forms and checking requests for the correct value. See the
:doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
:doc:`Cross Site Request Forgery protection documentation </ref/csrf>`.
X-Frame-Options middleware
--------------------------

View File

@ -374,7 +374,7 @@ CSRF_COOKIE_NAME
Default: ``'csrftoken'``
The name of the cookie to use for the CSRF authentication token. This can be whatever you
want. See :doc:`/ref/contrib/csrf`.
want. See :doc:`/ref/csrf`.
.. setting:: CSRF_COOKIE_PATH
@ -415,7 +415,7 @@ is rejected by the CSRF protection. The function should have this signature::
where ``reason`` is a short message (intended for developers or logging, not for
end users) indicating the reason the request was rejected. See
:doc:`/ref/contrib/csrf`.
:doc:`/ref/csrf`.
.. setting:: DATABASES

View File

@ -576,7 +576,7 @@ django.core.context_processors.csrf
This processor adds a token that is needed by the :ttag:`csrf_token` template
tag for protection against :doc:`Cross Site Request Forgeries
</ref/contrib/csrf>`.
</ref/csrf>`.
django.core.context_processors.request
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -70,7 +70,7 @@ csrf_token
^^^^^^^^^^
This tag is used for CSRF protection, as described in the documentation for
:doc:`Cross Site Request Forgeries </ref/contrib/csrf>`.
:doc:`Cross Site Request Forgeries </ref/csrf>`.
.. templatetag:: cycle

View File

@ -372,7 +372,7 @@ Other improvements
Other new features and changes introduced since Django 1.0 include:
* The :doc:`CSRF protection middleware </ref/contrib/csrf>` has been split into
* The :doc:`CSRF protection middleware </ref/csrf>` has been split into
two classes -- ``CsrfViewMiddleware`` checks incoming requests, and
``CsrfResponseMiddleware`` processes outgoing responses. The combined
``CsrfMiddleware`` class (which does both) remains for

View File

@ -141,7 +141,7 @@ Improved CSRF protection
------------------------
Django now has much improved protection against :doc:`Cross-Site Request Forgery
(CSRF) attacks</ref/contrib/csrf>`. This type of attack occurs when a malicious
(CSRF) attacks</ref/csrf>`. This type of attack occurs when a malicious
Web site contains a link, a form button or some JavaScript that is intended to
perform some action on your Web site, using the credentials of a logged-in user
who visits the malicious site in their browser. A related type of attack, "login
@ -426,7 +426,7 @@ CSRF Protection
---------------
We've made large changes to the way CSRF protection works, detailed in
:doc:`the CSRF documentation </ref/contrib/csrf>`. Here are the major changes you
:doc:`the CSRF documentation </ref/csrf>`. Here are the major changes you
should be aware of:
* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated and

View File

@ -341,7 +341,7 @@ Prior to Django 1.2.5, Django's CSRF-prevention system exempted AJAX
requests from CSRF verification; due to `security issues`_ reported to
us, however, *all* requests are now subjected to CSRF
verification. Consult :doc:`the Django CSRF documentation
</ref/contrib/csrf>` for details on how to handle CSRF verification in
</ref/csrf>` for details on how to handle CSRF verification in
AJAX requests.
.. _security issues: https://www.djangoproject.com/weblog/2011/feb/08/security/

View File

@ -52,7 +52,7 @@ Caching of anonymous pages could reveal CSRF token
Django includes both a :doc:`caching framework </topics/cache>` and a system
for :doc:`preventing cross-site request forgery (CSRF) attacks
</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
</ref/csrf/>`. The CSRF-protection system is based on a random nonce
sent to the client in a cookie which must be sent by the client on future
requests and, in forms, a hidden value which must be submitted back with the
form.

View File

@ -499,7 +499,7 @@ We've made various improvements to our CSRF features, including the
help with AJAX-heavy sites; protection for PUT and DELETE requests; and the
:setting:`CSRF_COOKIE_SECURE` and :setting:`CSRF_COOKIE_PATH` settings, which can
improve the security and usefulness of CSRF protection. See the :doc:`CSRF
docs </ref/contrib/csrf>` for more information.
docs </ref/csrf>` for more information.
Error report filtering
~~~~~~~~~~~~~~~~~~~~~~
@ -996,7 +996,7 @@ expression, such as periods.
CSRF protection extended to PUT and DELETE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Previously, Django's :doc:`CSRF protection </ref/contrib/csrf/>` provided
Previously, Django's :doc:`CSRF protection </ref/csrf/>` provided
protection only against POST requests. Since use of PUT and DELETE methods in
AJAX applications is becoming more common, we now protect all methods not
defined as safe by :rfc:`2616` -- i.e., we exempt GET, HEAD, OPTIONS and TRACE,

View File

@ -51,7 +51,7 @@ Caching of anonymous pages could reveal CSRF token
Django includes both a :doc:`caching framework </topics/cache>` and a system
for :doc:`preventing cross-site request forgery (CSRF) attacks
</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
</ref/csrf/>`. The CSRF-protection system is based on a random nonce
sent to the client in a cookie which must be sent by the client on future
requests and, in forms, a hidden value which must be submitted back with the
form.

View File

@ -51,7 +51,7 @@ Caching of anonymous pages could reveal CSRF token
Django includes both a :doc:`caching framework </topics/cache>` and a system
for :doc:`preventing cross-site request forgery (CSRF) attacks
</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
</ref/csrf/>`. The CSRF-protection system is based on a random nonce
sent to the client in a cookie which must be sent by the client on future
requests and, in forms, a hidden value which must be submitted back with the
form.

View File

@ -81,7 +81,7 @@ or for binary data, such as an image. A Web application that uses ``GET``
requests for admin forms is a security risk: it can be easy for an attacker to
mimic a form's request to gain access to sensitive parts of the system.
``POST``, coupled with other protections like Django's :doc:`CSRF protection
</ref/contrib/csrf/>` offers more control over access.
</ref/csrf/>` offers more control over access.
On the other hand, ``GET`` is suitable for things like a web search form,
because the URLs that represent a ``GET`` request can easily be bookmarked,
@ -335,7 +335,7 @@ from that ``{{ form }}`` by Django's template language.
.. admonition:: Forms and Cross Site Request Forgery protection
Django ships with an easy-to-use :doc:`protection against Cross Site Request
Forgeries </ref/contrib/csrf>`. When submitting a form via ``POST`` with
Forgeries </ref/csrf>`. When submitting a form via ``POST`` with
CSRF protection enabled you must use the :ttag:`csrf_token` template tag
as in the preceding example. However, since CSRF protection is not
directly tied to forms in templates, this tag is omitted from the