Andrei Sereda wrote:
> Hello Team,
>
> One quick question: is it possible to persist different permissions in
> current acegi implementation (acls package) ? It seems to me that only
> BasePermission is supported out of the box (see BasicLookupStrategy
> convertCurrentResultIntoObject() method) . What if I have my own
> PermissionA and PermissionB (they can be granted to the same domain
> object) ?
>
> Is new column (permission_class) in acl_entry table needed to have
> this functionality?
>
> Am I missing something ?
Hi Andrei
Interesting questions, and I'm delighted you're trying out the new ACL
package and provide much-needed feedback.
I agree it's necessary to provide some more sophisticated way of
allowing custom Permission instances to be returned and included in the
generated AclImpl. As such, perhaps we could change BasicLookupStrategy
so it uses a new interface:
public interface PermissionConverter {
public Permission buildPermissionFromMask(int mask);
}
This would be used instead of the following line:
Permission permission = BasePermission.buildFromMask(rs.getInt("MASK"));
As such, it should provide you a way to return any type of Permission
instance you wish.
Regarding your other question on mask checking, this one is by design. I
used some of the ideas from the Windows ACL subsystem, and it operates
this way. One benefit of the existing approach is we can have as many
permission _combinations_ as we like, whereas considering bits
individually limits us to 32 distinct permissions for an application
only. Using combinations also simplifies permission blocking logic. To
resolve your requirement, you have two basic options:
1. Add individual permission entries to a single domain object. This
would increase database rows, naturally.
2. Add cumulative permission masks to your AclEntryVoter etc
configurations. This would increase XML, but we could mitigate that to a
large extent with proper namespace support.
I am not entirely opposed to AclImpl using a new strategy interface that
provides the isGranted(Permission[] permission, Sid[] sids, boolean
administrativeMode) response. However, doing so would mean any
administrative tools or other extensions that people might build for the
ACL package would become bound to whatever approach that strategy used.
I'm therefore leaning slightly towards not providing the flexibility of
custom ACL, as I don't believe the second option above is too onerous.
Your comments on this are welcome, of course.
Cheers
Ben
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
