Luke Skibinski Holt wrote: > there is no per-record permission system > for users yet (or ever...). However this seems an unlikely scenario and > more often as not you will only want your users only looking/updating > data they have created.
I had an "aha!" moment on this topic last night. My reply here should probably be cross-posted to the dev list, since it's more "dev" in focus and not very helpful from a "user" perspective (yet). I believe the solution to adding this type of "fine grained" security where users can only view/update data they have personally created can be solved by what others call "row level security". It basically comes down to appending a special "where" clause to any database query in order to limit the amount of data retrieved or edited. I'm thinking a Django-ish definition of this "where" clause can be added as a parameter to the admin clause in the Meta section of Django model. Here is a link at how row level security is defined in an Oracle database: http://www.securityfocus.com/infocus/1743 I'm now abstracting that out and figuring out how to apply this at the Python/Django layer so it is available for all database backends, not just Oracle. On a side note, months ago, I made a proposal on the Django dev list for an "ACL-like" permissions scheme to enable the level of fine grained permissions that I wanted. Now I've seen the error of my ways (that a globally generic ACL system is over-engineering the problem) and believe implementing some version of row level security is the way to go. Some facts and examples to back up this belief is that the Rails framework doesn't provide any complicated ACL system out of the box. My "aha" moment came while reading two innocuous paragraphs in the chapter titled "Securing your Rails Application" (21.5) from the book, Agile Web Development in Rails. excerpt 1: """ An attacker might notice this URL and attempt to view the orders for other customers by manually entering different order ids. We can prevent this by using a constrained find( ) in the action. In this example, we qualify the search with the additional criteria that the owner of the order must match the current user. An exception will be thrown if no order matches, which we handle by redisplaying the index page. """ and exerpt 2: """ Another solution to this issue is to use associations in your application. If we declare that a user has_many orders, then we can constrain the search to find only orders for that user... """ The authors don't say the phrase "row level security", but that's exactly what it is. Some critiques to my ACL proposal argued for the example in exerpt 2. I now happen to agree with them. :-) -Jason
