Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default

On Wed, Oct 31, 2012 at 6:44 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:

> On Wed, Oct 31, 2012 at 7:29 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > The diff appears to be reversed. But that's easy enough to deal with
> during
> > commit.
>
> No, it's not reversed. I'm removing the explicit @csrf_protect
> decorators because all views are now protected by default.
>

Oh. Pardon my confusion. You are right, of course.

> > Have you verified that it works with django 1.2 as well? The production
> > deployment is on that quite old version still...
>
> Yeah, I developed and tested this on Django 1.2
>

Good.

So, one more thought. Is this going to break if the form is cached? That
is, the original form at e.g. http://www.postgresql.org/community/ for the
surveys is cached. That means that the CSRF token that's on the form
actually ends up being cached. Is the CSRF token going to be valid in those
cases, and is it actually going to protect us?

Forms that come in over https are safe, because we never cache those. Forms
re-rendering because they were sent by POST as well, they are not cached.
But a form that's over http and where the form itself uses GET will get
cached as it is now.

AFAICT it will break, because the CSRF stuff uses a cookie that wouldn't be
set, so there wouldn't be anything to match the token against. Or am I
missing something here?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/