Hi Ben,
Its funny how things like this work out, because I was just pondering a design issue on friday, and over the weekend, I thought I should probably email the acegi list about this, and then I read this email and it seems that you've already provided part, if not the whole solution.
In my project, I am incorporating the use of acegi security, and making specific use of the ACL for checking permissions of the user against the objects. I've gotten it working w/ doing checks on single items, like for instance, loading a single object from the data source, and allowing/rejecting the method invocation, but my next problem is when the method could potentially return more than one object.
Like say, if I made a method call to return all items in the database between dates A and B. I would need to run the security check on the collection after the data load to ensure that only the allowed objects are loaded.
So, this new afterinvocation provider you wrote up will help me with this situation?
-tim
On Nov 14, 2004, at 10:38 PM, Ben Alex wrote:
Hi everyone
I've just committed a (potentially very useful) new feature to Acegi Security. "After secure object invocation" allows you to throw an AccessDeniedException or modify the Object returned from your secure object invocation.
There's a new package, net.sf.acegisecurity.afterinvocation, which contains a couple of related providers. Both use AclManager and the integer bit masking provided by net.sf.acegisecurity.acl.basic. One of the providers throws an AccessDeniedException if the Authentication doesn't have an ACL permission for the returned Object (the required permission is defined in the application context). The other provider removes any item from a Collection if the Authentication doesn't have an ACL permission for that particular Collection element (again, the required permission is defined in the application context).
To help with "before" invocation ACL security, there's also a new AccessDecisionVoter called BasicAclEntryVoter. It votes to deny access if the Authentication doesn't have an ACL permission for a given method argument (the class type of the method argument, the permission required etc are application context defined).
The above isn't documented yet, but the Contacts sample application has been extensively refactored to use the above. Contacts are no longer owned by a single principal, but there is an ACL for each Contact. Permissions used include administer, delete and read. If the administer permission is held, the principal can modify the permissions list, adding or deleting ACL entries.
I'd be interested in what people think of these changes. In particular, please give Contacts a try and report any bugs to the list. To build it you'll need to CVS checkout, then from core do a "maven jar:install", then from samples/contact do a "maven war".
Best regards Ben
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
