     must be present and correct. If it isn't, the user will get a 403 error.
  
     This check is done by ``CsrfViewMiddleware``.
  
  4. In addition, for HTTPS requests, strict referer checking is done by
     ``CsrfViewMiddleware``. This means that even if a subdomain can set or
     modify cookies on your domain, it can't force a user to post to your
 
</s> remove    when using a session independent nonce, due to the fact that HTTP
 </s> add    when using a session independent secret, due to the fact that HTTP </s> remove form. The malicious user would have to know the nonce, which is user specific
 </s> add form. The malicious user would have to know the secret, which is user specific </s> remove    This cookie is set by ``CsrfViewMiddleware``.  It is meant to be permanent,
   but since there is no way to set a cookie that never expires, it is sent with
   every response that has called ``django.middleware.csrf.get_token()``
   (the function used internally to retrieve the CSRF token).
 </s> add    This cookie is set by ``CsrfViewMiddleware``. It is sent with every
   response that has called ``django.middleware.csrf.get_token()`` (the
   function used internally to retrieve the CSRF token), if it wasn't already
   set on the request. </s> remove :ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
 </s> add :ref:`CSRF protection works <how-csrf-works>` by checking for a secret in each </s> remove    outgoing POST forms.  The value of this field is the value of the CSRF
   cookie.
 </s> add    outgoing POST forms. The value of this field is, again, the value of the
   secret, with a salt which is both added to it and used to scramble it. The
   salt is regenerated on every call to ``get_token()`` so that the form field
   value is changed in every such response.
   When validating the 'csrfmiddlewaretoken' field value, only the secret,
   not the full token, is compared with the secret in the cookie value.
   This allows the use of ever-changing tokens. While each request may use its
   own token, the secret remains common to all.

     must be present and correct. If it isn't, the user will get a 403 error.
  
   When validating the 'csrfmiddlewaretoken' field value, only the secret,
   not the full token, is compared with the secret in the cookie value.
   This allows the use of ever-changing tokens. While each request may use its
   own token, the secret remains common to all.

     This check is done by ``CsrfViewMiddleware``.
  
  4. In addition, for HTTPS requests, strict referer checking is done by
     ``CsrfViewMiddleware``. This means that even if a subdomain can set or
     modify cookies on your domain, it can't force a user to post to your
keep add keep keep keep keep keep
 Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them

Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).

While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).

Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews. 
docs/ref/csrf.txt