I don't know how much of an issue it really is (or not), but I haven't really seen it being done right. Of all the examples I've found of devs implementing session authentication on top of piston and tastypie, (See here<http://www.sysadminpy.com/2011/11/ajax-and-tastypie-check-if-a-user-has-authenticated/>, here<http://stackoverflow.com/questions/7363460/how-do-i-check-that-user-already-authenticated-from-tastypie>and here<http://yml-blog.blogspot.co.uk/2009/10/django-piston-authentication-against.html>) none have re-enabled CSRF protection. (As far as I can tell.)
Having said that, I really just wanted to: 1. Get the core devs opinion on if would ought to actively do anything about this in core, since it's pretty easy to shoot yourself in the foot. 2. Raise the issue, so that there's at least more awareness that devs really should be making sure that any same-site AJAX driven APIs *do* get CSRF protection. [*] 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. I'm happy with that. Thanks for the feedback, Tom [*] Only relevant to APIs that support POST/PUT or DELETE operations of course. Read-only APIs will be just fine. On Saturday, 17 March 2012 03:24:04 UTC, Paul McMillan wrote: > > >> 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Dq4aUlP24nAJ. 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.
