It would be similar, except rather than hard coding the different assertions, they would be pulled dynamically from the DB. For example, in the case of an account, there could be multiple ways to assert privileges. One may be that you must be the owner, in which case the user_id matches directly with both records. Another case may be that you must share the same branch as the account.
In this scenario, picture a table with three columns, on the left the requesting object, on the right the resource (account). On the left there is a drop down with a list of objects, so we pick "user", which once selected populates another drop down underneath, which you select a field or relation, in this case the relation to "branch". Then on the branch object you select a field "id" in the next populated drop-down. On the right side, we do the same. So on the left side we are selecting the user's branch id, and on the right side the account's branch id. Of course, these could easily be a field directly on both tables, for the sake of this example we'll pretend that both can have many branches so it's a m2m. Then in the middle you have your comparison operators drop down, and we select "==". And there we have a rule. These could be stacked to allow for multiple rules to act as one and/or each rule act individually. They could be added/removed on the fly, and no programming would be needed. This would at first be a lot of work to set up, but in the long run could save a whole lot of time and let personnel that don't know any programming to manage fine-grained access control in the app. This is just what i've been tossing around in my head. My main concern is overhead. Jason On Wed, Oct 15, 2008 at 10:36 AM, Colin Guthrie <[EMAIL PROTECTED]>wrote: > I wrote: > > Do you see your system supporting asserts or does this go beyond a > > drop-in module? > > Jason Eisenmenger wrote: > >> Yes and this is one of the things I've spent the most time thinking about. >> >> Some kind of GUI that lets you select the required relationships between >> not just roles and resources, but between one object and another. >> > > Cool. I'd be interested in hearing how you solve this particular problem: > How do you know what "Resources" a system supports beyond simple module > controllers. > > e.g. consider you have a custom route that matches: > article/0-9]+/edit > > It drops into the article controller and the edit action with the > additional param of article_id, you'd really need to check that the given > role has access to the specific resource with that id. In my system I'd use > my article object itself as the resource and pass this through the ACL > methods which ultimately finds it's way to the assert and I can type check > it and extract the article id, author etc. and compare that against the > current user to make sure they have permission. This works pretty well for > me (with my fix from ZF-4460). > > I guess you'd probably create an top level folder called assertions or > something and allow this to be glued together in your ACL editor, but I > suspect the assertions would have to load up the details for the article > independently (by using the article id from the request) rather than using > the resource object itself. > > Anyway, thanks for sharing the screen cast, it helps me work on my own > strategy even if I don't use your stuff directly :) > > > Col > > > > > > > > > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited [http://www.tribalogic.net/] > Open Source: > Mandriva Linux Contributor [http://www.mandriva.com/] > PulseAudio Hacker [http://www.pulseaudio.org/] > Trac Hacker [http://trac.edgewall.org/] > >
