toastdriven/django-tastypie — Issue #332: apply_limits giving false sense of security?
Author: gingerlime
Created: 2012-01-17 11:42:26+00:00
State: open

I've been looking into the `apply_limits` authorization mechanism. This is a very powerful authorization method in Tastypie, and a great feature I really like. However, I felt like I was either trusting it too much, or just not paying enough attention (although I couldn't find anything in particular I was missing in the docs or elsewhere).

`apply_limits` works great for read access (via GET) to resources, by adding an optional filter to the queryset. It also seems to work well with related resources, and DELETEs.

The problem lies with POST/PUT requests.

From what I gathered, and please correct me if I'm wrong, the `apply_limits` is not used at all with `obj_create`. If you understand django querysets etc, you could expect this. When a new object is created and saved, there's no direct use for the filter method, and there's no object_list... (well, not as such). This is the first and main limitation I see currently. It might be (or probably is?) by-design, but it still seems like a potential blind-spot for API developers using and trusting apply_limits to also work on POSTs.

The second, related issue, is with PUT. Whilst `obj_update` does use the `apply_limits` method (via the `obj_get` method), if the apply_limits, erm, applies limits, and e.g. returns an empty list of objects, `put_detail` will fall back to `obj_create` - which as mentioned will not apply any such limits. Whilst it won't let you update the object you expected to update, it will create a new object for you.

Is this by-design? Should the documentation highlight this more clearly? As I see it, it might give a false sense of security and leave APIs open to authorization issues they don't necessarily anticipate.

If this is not desired, then I wonder what's the best approach to resolve this in a generic way? I was thinking that maybe adding an `apply_write_limits` method can/should be added specifically for object creates/updates (e.g. allowing to override certain fields with different values), or perhaps the current validation methods are sufficient?