Hi Jason. Your scenario only covers a very basic scenario, where 1 user can do anything to a particular record. It kind of falls down when you need to assign rights to actions.
ie..group/user X can add a new invoice, but only 'group/user Y' can modify an existing invoice. So while a constrained find *can* do what you are after, you will end up replicated ACL-like code throughout your application, and it might make it hard to change your application at a later stage when the design changes. When I finish a couple of more things on my current-django plaything I need to work on a ACL system.. Jason.. if you need one as well.. maybe we can co-operate.. the design pattern for a ACL system is well established..it is just a matter of getting it down in code I think. 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. :-) > > -Jason > > -- [EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti
