On 2/8/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > > 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. :-) >
+1 Great idea. I also think the Model can support user relative record set is very useful. And I also need it. -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit
