Opened 4 weeks ago
Last modified 3 weeks ago
#37032 assigned Cleanup/optimization
Clarify that django.template.context_processors.csrf is enabled by default in ref docs
| Reported by: | Christian Finnberg | Owned by: | VIZZARD-X |
|---|---|---|---|
| Component: | Documentation | Version: | dev |
| Severity: | Normal | Keywords: | csrf, context processor |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
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_tokentemplate 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.
Change History (6)
follow-up: 2 comment:1 by , 4 weeks ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 4 weeks ago
Replying to Sarah Boyce:
The docs are correct, the template tag gets the
csrf_tokenwhich 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
comment:3 by , 4 weeks ago
| Summary: | Documentation for django.template.context_processors.csrf is incorrect or inaccurate → Clarify that django.template.context_processors.csrf is enabled by default in ref docs |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → Cleanup/optimization |
Sure, would you like to submit a patch?
comment:4 by , 4 weeks ago
| Resolution: | invalid |
|---|---|
| Status: | closed → new |
Reopening so status gets updated from invalid to new.
comment:5 by , 4 weeks ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:6 by , 3 weeks ago
| Has patch: | set |
|---|
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 there's anything.
The docs are correct, the template tag gets the
csrf_tokenwhich 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