This was an excellent and well-put argument. As a newcomer to
Django-developers, I was a bit confused by the {% csrf token %} inclusion
(that breaks my code).

Now, if I can just find some working code to use as a model ...

-wolf

On Dec 30, 2009 5:23 PM, "Wim Feijen" <wimfei...@gmail.com> wrote:

Hello,

For the past two days, I've been reading up on CSRF on the groups and
on the excellent wiki by Luke Plant, and giving it a lot of thought.
CRSF-protection should be on by default, that is clear.

What I want to talk about is whether we can make the implementation a
little bit less intrusive.

At the moment, (and please correct me if I am wrong), every form
template needs a {% csrf_token %} and RequestContext passed to it. As
I understand it, forms from existing, not yet upgraded applications
stop functioning. And every new form template written needs to include
the same extra variable {% csrf_token %} in the template.

Personally, I'd like to find a solution which requires less work by
the programmer and by default, handles all common cases, while any
rare cases still require conscious effort of the programmer. I really
recommend reading "Less is more", by 37 signals. My proposal for such
a solution is:

1. CSRF protection should be on by default.
2. Rendering {{ form }} should include the token by default.
3. When rendering a form "by hand", the token should be inserted by
the programmer. This works like rendering a formset; and I don't find
it beautiful, but workable.

Benefits are:
1. Old code works.
2. Writing a new template stays as simple as it is.

Drawbacks:
1. Public forms shouldn't be protected. In my views, when I render a
non-public form it is always preceded by either a login_required or a
permission_required decorator and I was thinking in the line of using
that as a trigger.
2. Forms which post to other sites should not leak the token.
Therefore, each Form should definitely have a optional argument
(enable_csfr = False). So the default is protect and the programmer
doesn't need to do anything about it, and there is an option to
disable the token on the form level. So, what happens if a programmer
forgets to disable the token? The form will leak the token. Now I'd
like to make some assumptions and these are:
a) most Django forms post to their own site.
b) when I post to a foreign site, I apparently trust the site and am
looking forward to cooperate with it. I consider it higly unlikely
that this site will intercept my token and use it for ill.
So in the case the programmer makes a mistake and forgets to disable
the token, it still is unlikely he endangers his site.

I really hope this may inspire you and help in implementing a less
intrusive way of CSRF-safe forms. As you, I am looking for a solution
which benefits us most and at the same time, has the least drawbacks.
Please correct me if I am wrong and take this message in the spirit it
is meant, that is: to describe an idea.

Best regards,

Wim Feijen

--

You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


Reply via email to