Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default
| От | Magnus Hagander |
|---|---|
| Тема | Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default |
| Дата | |
| Msg-id | CABUevEy=JtSDbU+RPxaTihkUuCvUzCGuyPvWrfr=RpWgRH_2Ww@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default (Marti Raudsepp <marti@juffo.org>) |
| Ответы |
Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF
protection required by default
|
| Список | pgsql-www |
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:No, it's not reversed. I'm removing the explicit @csrf_protect
> The diff appears to be reversed. But that's easy enough to deal with during
> commit.
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 productionYeah, I developed and tested this on Django 1.2
> deployment is on that quite old version still...
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/
В списке pgsql-www по дате отправления: