On Sep 23, 1:06 am, Simon Willison <[EMAIL PROTECTED]> wrote: > Since all form.protect(response) actually does is ensure that there's > a csrf cookie, you should only actually have to do it once for one of > the forms.
Unsurprisingly, I've been totally over-engineering this. There's no need for form.protect(response) at all - in fact, the form doesn't need to have anything to do with the response object. This dramatically simplifies things - in fact, it takes us back to the original proposal of a SafeForm that just takes the request object as an argument to its constructor. CSRF attacks are a problem for systems where an action is only meant to be available to a specific logged in user. This user is inevitably identified by a unique cookie. This is normally a session cookie, hence many CSRF protection mechanisms key their hidden form token off the session cookie. That's also what Django's CSRF middleware does. I like to be able to avoid sessions where possible, which is why I didn't want SafeForm to use the session cookie and thought it would need to set a cookie itself. But even if an application isn't using sessions, it's still going to need to use one or more cookies that are unique to the user. I think we solve this with a setting, the default of which looks like this: CSRF_COOKIES = [SESSION_COOKIE_NAME] SafeForm creates its csrf_token based on a hash of the cookie values for the keys in that list. It's a list because some authentication cases may rely on more than one cookie to uniquely identify the user (rare but possible). By default, it will use the Django session cookie. If you're not using sessions in your app (you're using a signed cookie called 'current_user' for example) you can specify that in the CSRF_COOKIES session. So, the bit about the SafeForm needing access to the response was a red herring. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
