From d3db878e4beff057400dd780c24f3601a5d31f95 Mon Sep 17 00:00:00 2001 From: Thomas Chaumeny Date: Fri, 31 Oct 2014 23:39:46 +0100 Subject: Moved CSRF docs out of contrib. --- docs/topics/forms/index.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/topics/forms') diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 215b0d74c2..c20acde52f 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -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 -` offers more control over access. +` 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 `. When submitting a form via ``POST`` with + Forgeries `. 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 -- cgit v1.3