Clarify that django.template.context_processors.csrf is enabled by default in ref docs

[Christian Finnberg]

Documentation for django.template.context_processors.csrf in ​https://docs.djangoproject.com/en/dev/ref/templates/api/#django-template-context-processors-csrf is not accurate. It says:

This processor adds a token that is needed by the csrf_token template tag for protection against Cross Site Request Forgeries.

But the csrf_token template tag is independent of this context processor. This content processor adds a csrf_token variable that can be used for protection against CSRF, but it seems that this is like a "legacy" method. The recommended way or at least the way Django is configured by default, is to enable the django.middleware.csrf.CsrfViewMiddleware middleware, that adds the crsf_token template tag and works independently of this context processor.

So a different definition may be better. Something like:

If this processor is enabled, every RequestContext will contain a variable csrf_token with a CSRF token, or the string 'NOTPROVIDED' if it has not been provided by either a view decorator or the middleware. Notice that the csrf_token template tag (not this context processor) is the preferred way to add the CSRF token to the forms.

In any case I think this component's text must be corrected somehow.

[Sarah Boyce]

The docs are correct, the template tag gets the csrf_token which is added by the context processor. However, this context processor is enabled by default regardless of your settings. See ​https://docs.djangoproject.com/en/6.0/ref/templates/api/#:~:text=In%20addition%20to%20these,option

[Christian Finnberg]

Replying to Sarah Boyce:

The docs are correct, the template tag gets the csrf_token which is added by the context processor. However, this context processor is enabled by default regardless of your settings. See ​https://docs.djangoproject.com/en/6.0/ref/templates/api/#:~:text=In%20addition%20to%20these,option

Thanks for the correction. I didn't noticed your highlighted paragraph. Sorry for the noise then.
In any case I still think it would be helpful for the developer reading the documentation to get this information also from the django.template.context_processors.csrf part. At least I was reading the part of the documentation about context processors and I was confused about this one

[Sarah Boyce]

Sure, would you like to submit a patch?

[Natalia Bidart]

Reopening so status gets updated from invalid to new.

[VIZZARD-X]

Added a small note to make it clearer and more readable, along with a cross-reference to Using RequestContext for more info (seemed more in line with the Django way of doing things). This should suffice, let me know if anything else is needed.

​PR

[Sarah Boyce <42296566+sarahboyce@…>]

In dca76b1:

Fixed #37032 -- Documented that the CSRF context processor is always enabled in its reference documentation.

[Sarah Boyce <42296566+sarahboyce@…>]

In 1cea813:

[6.1.x] Fixed #37032 -- Documented that the CSRF context processor is always enabled in its reference documentation.

Backport of dca76b15c62a1118325b71678ce3235e2231198d from main.

[Sarah Boyce <42296566+sarahboyce@…>]

In 3815906f:

[6.0.x] Fixed #37032 -- Documented that the CSRF context processor is always enabled in its reference documentation.

Backport of dca76b15c62a1118325b71678ce3235e2231198d from main.