TL;DR
If a request using django tastypie is not authorized, please make sure to raise Unauthorized() exception in your _detail authorization methods in Tastypie v0.9.12.
The longer version
On one of my previous posts I wrote at length about django-tastypie authorization and gave some tips and tricks on how to work more flexibly and securely with this framework. A lot has happened since, and it was hard to keep track of all the various changes and updates to Tastypie.
Since version 0.9.12, the authorization mechanisms in tastypie changed rather radically, and that’s a very good improvement. It plugged some holes with nested resources and authorization, and made authorization decisions more granular. From a simple is_authorized and apply_limits, now each operation can be authorized, broken down to CRUD elements (create, read, update, delete). Each element is authorized for _list and _detail operations (I’ll try to cover this in more depth on a follow-up post at some stage).
For now, I just wanted to highlight an important pitfall you might want to avoid when using the new tastypie authorization that could leave you exposed. There’s a fix in the pipeline very soon, but until then, you should protect yourself by making a small change to your authorization methods, and the _detail ones in particular
The crux of the issue is that the _detail authorization methods should make a binary decision – is this authorized? (yes/no). If the method returns True, or does nothing, the request is authorized. If the method returns False or raises an Unauthorized exception, the request should be blocked.
The glitch is that if your authorization _detail functions return False, the request still goes through and is effectively authorized. Until the fix is in place, please make sure to raise Unauthorized() exception if you’re using Tastypie v0.9.12.
