>> One idea to mitigating this in Django core that I've considered would be >> introducing a '@csrf_defered' decorator
> Practically speaking, I think this might be ok and would cover the > majority of real cases. But at the very least it means that this > decorator should live in contrib.sessions, not in the core CSRF code. I would be opposed to this code in any shipped part of Django. It certainly could be built as a third party module (if we don't have the hooks necessary to do this, we can discuss them). My main objection is that CSRF is not a topic which should be deferred, or maybe on, or anything except absolutely positively explicitly on or off. Introducing a deferred format encourages developers to ignore it, until it causes problems, at which point they will do exactly the same thing as they do now, and turn it off. It's easy enough to screw up already - adding a "maybe on" is going to bite developers even more than the current format, since it will be even easier to write code that works most of the time, for most users, but not all of the time, for all users. I fall into the camp of "you should understand what you're doing when you turn CSRF protection off". If the framework authors want to support session based authentication, I believe they're capable of doing it correctly. Until then, if users want to hack session based auth onto the frameworks, they should be careful and understand what they're doing. For readers who have not inspected it yet, Django's CSRF implementation is quite instructive: https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py -Paul -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
