Re: An idea to eliminate {% csrf token %}
On Friday 01 January 2010 16:45:19 Wim Feijen wrote:
> I am not talking about SafeForm. I am sorry I wasn't clear before,
> but in fact, what I want to propose is to include the lines:
> name='csrfmiddlewaretoken' value='1234567890abcdef etc' />
> by default when rendering a form with {{ form }}.
>
> Would that be possible? I know of several unwanted side-effects,
> which I believe we will be able to deal with using the reasoning
> in my first post, but please correct me if I overlooked any
> loopholes.
It's not possible, unless you pass the request object to the Form
instance, which requires changing the API for Form to something like
SafeForm. That's the problem.
Luke
--
"I washed a sock. Then I put it in the dryer. When I took it out,
it was gone." (Steven Wright)
Luke Plant || http://lukeplant.me.uk/
--
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.
Re: An idea to eliminate {% csrf token %}
Hi Luke,
Thanks for your quick response.
I've read the discussions about CSRF and SafeForm, in fact I already
did before posting my message. Because of your excellente wiki the
threads were easy to find.
I am not talking about SafeForm. I am sorry I wasn't clear before, but
in fact, what I want to propose is to include the lines:
by default when rendering a form with {{ form }}.
Would that be possible? I know of several unwanted side-effects, which
I believe we will be able to deal with using the reasoning in my first
post, but please correct me if I overlooked any loopholes.
I am looking forward to your response.
Thanks,
Wim
On Dec 31 2009, 2:29 am, Luke Plant wrote:
> Hi Wim,
>
> Your suggestion sounds something like Simon's SafeForm. While some
> elements of that proposal may end up in Django, it turns out that
> implementing SafeForm as the default solution requires *bigger*
> changes to existing code than adding the csrf_token, because you would
> need to pass additional info from the request to Form for it to be
> able to do the CSRF checks. It also only works if you are using
> Django Forms and rendering them via {{ form }} (instead of field-by-
> field, for instance).
>
> If you want to see how we got to where we are, have a look at this
> thread:http://groups.google.com/group/django-
> developers/browse_thread/thread/3d2dc750082103dc/f3beb18c27fb7152
>
> (OK, that was a nasty trick - the thread is huge, we discussed this
> nearly to death, but that's why I'm not going to repeat all the
> arguments here).
>
> Also, you can use CsrfResponseMiddleware as an interim measure to stop
> your code from breaking, so the change to require csrf_token isn't
> quite so bad.
>
> Thanks,
>
> Luke
>
> --
> "It is a truth universally acknowledged, that a single man in
> possession of a good fortune, must be in want of a wife." (Jane
> Austen)
>
> Luke Plant ||http://lukeplant.me.uk/
--
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.
Re: An idea to eliminate {% csrf token %}
Hi Wim,
Your suggestion sounds something like Simon's SafeForm. While some
elements of that proposal may end up in Django, it turns out that
implementing SafeForm as the default solution requires *bigger*
changes to existing code than adding the csrf_token, because you would
need to pass additional info from the request to Form for it to be
able to do the CSRF checks. It also only works if you are using
Django Forms and rendering them via {{ form }} (instead of field-by-
field, for instance).
If you want to see how we got to where we are, have a look at this
thread: http://groups.google.com/group/django-
developers/browse_thread/thread/3d2dc750082103dc/f3beb18c27fb7152
(OK, that was a nasty trick - the thread is huge, we discussed this
nearly to death, but that's why I'm not going to repeat all the
arguments here).
Also, you can use CsrfResponseMiddleware as an interim measure to stop
your code from breaking, so the change to require csrf_token isn't
quite so bad.
Thanks,
Luke
--
"It is a truth universally acknowledged, that a single man in
possession of a good fortune, must be in want of a wife." (Jane
Austen)
Luke Plant || http://lukeplant.me.uk/
--
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.
Re: An idea to eliminate {% csrf token %}
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" 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
.
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.
