On Wed, Oct 31, 2012 at 6:44 PM, Marti Raudsepp <marti@juffo.org> wrote:
On Wed, Oct 31, 2012 at 7:29 PM, Magnus Hagander <magnus@hagander.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?
