Hi Ben, >> I was wondering why not do the following in AccessControlEntry interface: >> public Permission[] getPermissions(); >> public int getMask(); >> public String getPattern()
>Permission is an interface, for which BasePermission and >CumulativePermission are both concrete implementations. The getMask() >and getPattern() are both defined on the Permission interface. We don't >have these methods defined on AccessControlEntry because doing so would >bind AccessControlEntry unnecessarily to the notion of an >AccessControlEntry has cumulative permissions whereas often a single >permission (a BasePermission) is all that is needed. It may be true that for an AccessControlEntry often a single permission (a BasePermission) is all that is needed but it was causing us problems because this is not always true. Could you explain how you envision this being modeled in the database? For us we modeled an ACE as a one to many relationship with base permissions. This allowed us to remove the need for a cumulative permission. When we tried to implement the provided interface it gave us trouble at the database level. We found we didn’t have transparency when looking only at the tables. For example if an ACE had read and write, it would have had a row with an integer value of r+w. We would then need to look at the java code to translate this value. This also meant instead of storing just the base permissions and linking to them from an ACE, we now need to store every combination of integer permission values and link to those. We also ran into trouble when the base permissions needed to be explained to non-technical users. For example (W)rite doesn’t mean a whole lot depending on what the user is going to do even though the developers have assigned permissions based on the base permission. This lead us to create another table that linked the base permissions and object type to explain what each one meant in the context of the particular object. >I've added JavaDocs as follows: > > /** > * Indicates the a Permission is being granted to the relevant Sid. > * If false, indicates the permission is being revoked/blocked. > * > * @return true if being granted, false otherwise > */ > public boolean isGranting(); I guess I still don’t understand this. If you’re going to revoke the permission then why not just ether delete the ACE or change its permission value(s) depending on the mutability of the ACE. I was also wondering how does this work if it has cumulative permission and you want only some of the permissions to be granted? Does the granting flag have to apply to all parts of the cumulative permission? I thought this might be used for inheritance to override a single permission but I couldn’t see how it would work to override only certain permissions. Thanks again for all the help. Best, -Nate ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
