[3.1.x] Fixed #32065 -- Restored leading dot to CSRF_COOKIE_DOMAIN examples.

Partially reverts afd375fc34.

Thanks to Tim Graham for review.

Backport of 3d4ffd1ff0 from master
This commit is contained in:
Carlton Gibson 2020-10-06 10:12:04 +02:00
parent 3add635ff7
commit 1f8dbc8fa9
2 changed files with 5 additions and 5 deletions

View File

@ -276,10 +276,10 @@ The CSRF protection is based on the following things:
enough under HTTP.)
If the :setting:`CSRF_COOKIE_DOMAIN` setting is set, the referer is compared
against it. This setting supports subdomains. For example,
``CSRF_COOKIE_DOMAIN = '.example.com'`` will allow POST requests from
``www.example.com`` and ``api.example.com``. If the setting is not set, then
the referer must match the HTTP ``Host`` header.
against it. You can allow cross-subdomain requests by including a leading
dot. For example, ``CSRF_COOKIE_DOMAIN = '.example.com'`` will allow POST
requests from ``www.example.com`` and ``api.example.com``. If the setting is
not set, then the referer must match the HTTP ``Host`` header.
Expanding the accepted referers beyond the current host or cookie domain can
be done with the :setting:`CSRF_TRUSTED_ORIGINS` setting.

View File

@ -313,7 +313,7 @@ Default: ``None``
The domain to be used when setting the CSRF cookie. This can be useful for
easily allowing cross-subdomain requests to be excluded from the normal cross
site request forgery protection. It should be set to a string such as
``"example.com"`` to allow a POST request from a form on one subdomain to be
``".example.com"`` to allow a POST request from a form on one subdomain to be
accepted by a view served from another subdomain.
Please note that the presence of this setting does not imply that Django's CSRF