#9977: CSRFMiddleware needs template tag
---------------------------------------------+------------------------------
Reporter: bthomas | Owner: lukeplant
Status: assigned | Milestone:
Component: Uncategorized | Version: SVN
Resolution: | Keywords: csrf
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------+------------------------------
Changes (by lukeplant):
* owner: nobody => lukeplant
* status: new => assigned
Comment:
The argument against post-processing is that it is ugly, it is a
performance hit on '''every''' page and that it kills the ability to
stream responses.
I agree that having to add this every time is a bit of a pain, and I do
like the way you can just do "install and forget" with the post-processing
method. I made these points myself in this thread:
http://groups.google.com/group/django-developers/msg/1afbe3a79db00b71 .
But the above criticisms are big ones, and no-one has managed to come up
with a solution that involves less work than this template tag method. I
have converted several applications to use it, and it was very little work
-- a regex to find all POST forms is most of the work.
In response to the DRY criticism: one could argue that every time you
write {{{<form action="" method="POST">}}} or {{{ {% extend "base.html" %}
}}} you are 'repeating' yourself, but the only way to get rid of that kind
of thing is to rely on conventions or other implicit behaviour, and at
some point we say "explicit is better than implicit". There is a trade-
off between repeating yourself and being explicit. Given the other things
we are trying to satisfy, putting the compromise at this point seems
reasonable. Also, if you forget the template tag, you are at least secure
by default, and you will find out pretty quickly that the form does not
work.
This method does work cleanly if you use both the tag and the middleware
(this is explained in detail in the docs, along with a migration guide).
If you obsess about HTML perfection, even though it is invisible to users,
then you might be bothered about the field being inserted twice, but I'm
not, especially as the result is perfectly valid HTML that works perfectly
on all browsers. A bigger concern is the performance hit for pages that
don't need the post-processing, and the `...@csrf_response_exempt` decorator
will fix that for you (as well as fixing double insertion of the field).
> I don't think the _make_token salt needs to be configurable; just use a
literal string to make the hash distinct from other uses of SECRET_KEY.
I'd suggest prefixing the string to the secret rather than appending it
Agreed, I'll change it to do that.
--
Ticket URL: <http://code.djangoproject.com/ticket/9977#comment:23>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
