Hi,
First of all: Merry Christmas to all of you...
I was just looking a bit more in depth on the multiple inheritance of roles in ZF ACL.
One of the choices that was made, was that the first inherited role examined that provided an access rule on the resource would be taken into consideration.
From the docs "Zend_Acl resolves this ambiguity by completing a query when it finds the first rule that is directly applicable to the query".
I've been thinking about this a lot now and my feeling is that this doesn't really correspond to what you do in practise -for every project I've worked for anyway. Most of the times you get the positive union of the groups, so if you have 3 parent rules and 2 contradict, you get the positive (allow) access.
Suppose 2 groups and 2 resources:
* group 1 has allow access on resource1 and deny access on resource 2.
* group 2 had deny access on resource1 and allow access on resource 2.
When you get both roles assigned, you will basically just get group 1 or group 2 because they "contradict" each other. While what you want is:
> newgroup has allow access on resource 1 and allow access on resource 2.
To make ZF as flexible as possible, I think it might be useful to have this behaviour configurable. Default behaviour could be as it is now, but with the possibility to choose for deny or allow precidence.
If you choose DENY precidence, the above example would yield:
> newgroup has deny access on resource 1 and deny access on resource 2.
If you choose ALLOW precidence, the above example would yield:
> newgroup has allow access on resource 1 and allow access on resource 2.
What do you guys think? Does this make sense or is it just the ramblings of someone who should stop thinking about ACL on christmas day? ;-)
PS For now I will change the way I've set up my access and leave out the deny rules on resources if possible (if there is no rule, there will automatically be no access, but it won't be taken into consideration when inheriting from it).
With kind regards,
Jeroen
2008年12月25日星期四
订阅:
博文评论 (Atom)
没有评论:
发表评论