Why not remove csrfmiddlewaretoken in CsrfViewMiddleware from request.POST?

[mucisland]

I posted this also in Django users but got no response - maybe the
question is too stupid or it was the wrong group...

Here's the deal:

I have various views which break on the additional csrfmiddlewaretoken
in request.POST when using the recommendet CSRF protection with
CsrfViewMiddleware and {% csrf_token %}.

Why don't we just remove the csrfmiddlewaretoken from request.POST in
CsrfViewMiddleware before the request hits the views?

I did it like this (patch on middleware/csrf.py 1.2.1 final):

11a12
> from django import http
162a164,167
> tmp_post = request.POST.copy()
> del tmp_post['csrfmiddlewaretoken']
> request.POST = http.QueryDict(tmp_post.urlencode())

My app seems to work and the CSRF protection is now completely
transparent to the views. Only the templates and the
MIDDLEWARE_CLASSES need to know about it.

Since this is so obvious I probably miss something important here, but
I cannot see it and I would be glad if someone could have a look into
it.

Thanks and Best Regards,
Dirk

[Russell Keith-Magee]

On Thu, Aug 26, 2010 at 12:55 AM, mucisland <dirk.j...@googlemail.com> wrote:
> I posted this also in Django users but got no response - maybe the
> question is too stupid or it was the wrong group...
>
> Here's the deal:
>
> I have various views which break on the additional csrfmiddlewaretoken
> in request.POST when using the recommendet CSRF protection with
> CsrfViewMiddleware and {% csrf_token %}.
>
> Why don't we just remove the csrfmiddlewaretoken from request.POST in
> CsrfViewMiddleware before the request hits the views?

Personally, I'm not really in favor of messing with POST data. I don't
have a particular use case that requires the presence of the CSRF
token, but POST data is an immutable dictionary. Absent of a pretty
compelling reason, I don't see why we should violate that
immutability.

So - what exactly is the problem? Saying that you have "views that
break on the CSRF token" says to me "fix your views", not "fix
Django". The CSRF token is a key in a dictionary. Ignore the CSRF key.
If you're using Django's forms, the presence of extra form data won't
affect form processing -- that's what makes it possible to process
multiple Form objects in a single view. What what exactly are you
doing that is breaking on the existence of a CSRF token?

Yours,
Russ Magee %-)

[mucisland]

On Aug 26, 3:03 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

> On Thu, Aug 26, 2010 at 12:55 AM, mucisland <dirk.juel...@googlemail.com> wrote:
> > I posted this also in Django users but got no response - maybe the
> > question is too stupid or it was the wrong group...
>
> > Here's the deal:
>
> > I have various views which break on the additional csrfmiddlewaretoken
> > in request.POST when using the recommendet CSRF protection with
> > CsrfViewMiddleware and {% csrf_token %}.
>
> > Why don't we just remove the csrfmiddlewaretoken from request.POST in
> > CsrfViewMiddleware before the request hits the views?
>
> Personally, I'm not really in favor of messing with POST data. I don't
> have a particular use case that requires the presence of the CSRF
> token, but POST data is an immutable dictionary. Absent of a pretty
> compelling reason, I don't see why we should violate that
> immutability.

Thanks for your response, Russell.

The reason I see for violating the POST immutability is that I thought
of CSRF protection as a middleware protocol which should be invisible
to the views because their business is to handle the application
logic, and the framework handles the CSRF protection.

> So - what exactly is the problem? Saying that you have "views that
> break on the CSRF token" says to me "fix your views", not "fix
> Django". The CSRF token is a key in a dictionary. Ignore the CSRF key.

That's an advice which forces me to touch all views after enabling
CSRF protection. I understand that you consider a view which relies on
only known POST keys is bad Django style, but I have found some of
them in my apps.

> If you're using Django's forms, the presence of extra form data won't
> affect form processing -- that's what makes it possible to process
> multiple Form objects in a single view. What what exactly are you
> doing that is breaking on the existence of a CSRF token?

I'm not going to embarrass myself and post my code ;-) but I use the
POST keys to encode form selections into a single number which is
stored in the session data (to enable permanent site configuration
with cookies). This encoder was irritated by the new key.

I'm going to fix this and forget about modifying POST in the
middleware.

> Yours,
> Russ Magee %-)

Thanks for your insight. Since Django is very flexible, it's sometimes
not easy to see the way of best practice ;-)

Best Regards,
Dirk