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
apply_limits, now each operation can be authorized, broken down to CRUD elements (
delete). Each element is authorized for
_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.