#15352 closed (wontfix)
id="csrfmiddlewaretoken" regression
| Reported by: | jl6 | Owned by: | nobody |
|---|---|---|---|
| Component: | Template system | Version: | dev |
| Severity: | Keywords: | csrf token | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Once upon a time, it was noted in issue #1827 that adding an extra attribute to the generated {% csrf_token %} would be a good idea. Changeset [2899] implemented it. However, that code path seems to have been deprecated in favor of the modern CSRF-protection system, whose token does not feature the id attribute. This is what {% csrf_token %} currently generates:
<input type='hidden' name='csrfmiddlewaretoken' value='296dfe12298a615b8a5db897af2d1697' />
Fast forward to the AJAX-CSRF-related changes in the latest Django 1.2.x releases, where the example fix (http://www.djangoproject.com/weblog/2011/feb/08/security/) is a piece of jQuery referencing the CSRF token value using $("#csrfmiddlewaretoken") - which relies on the token being locatable via its id attribute. If somebody uses {% csrf_token %} in their form template, this fix will not work for them.
Would it be a good idea to add this id attribute back into the token?
The example code was in error, as noted in the errata blog post: http://www.djangoproject.com/weblog/2011/feb/10/security-errata/
The new version does not include the ID attribute deliberately, for the reason that in the case of multiple instances of
{% csrf_token %}on a page you need to ensure that only one has the ID attribute (for HTML validity), and doing this in the new version is probably not possible, or would be extremely hacky at best.