Sergio Berna wrote:
Andy,
I agree that filtering the method response is a fascinating area. The only problem I have always found on filtering a method response is that it doesn't scale properly when performance is an issue. I'm particularly thinking on Collections here, where the full collection check for permissions would degrade performance on big enough collections.
Maybe providing "intelligent" collections and Iterators that perform the
security check when accessed could be a wiser approach for that area (like
hibernate for lazy load modification). That would imply that a response
from a method would be a proxy on the original object that enforces all
the security restrictions specified.
A generated object wrapper for collections and POJOs that enforces security would be an interesting extension. The necessary hook to add the wrapper is already provided via the AfterInvocationManager. An alternative approach would be to use AspectWerks, rather than something like CGLIB. The nice thing about AspectWerks is a suitable AbstractSecurityInterceptor subclass could also be written that enforces security on domain object instances.
In terms of performance, I would never advocate running the existing ACL-based AfterInvocationProviders against large Collections, because not only is there a performance issue at a JVM level to iterate every Collection element, but far more importantly there is the JDBC cost of obtaining the AclEntry[]s from the AclManager. Whilst they do get cached, the AclEntry[]s obviously need to come from the database at some point.
This Collection size issue reminds me of someone who was looking for a solution to paginating their Collection results, where the AfterInvocationManager may remove elements. They wanted to ensure the page size was always honoured, even if certain elements were removed due to security. A solution I think was suggested was to retrieve more elements than needed, knowing the AfterInvocationManager would likely remove some of them. I think an alternative was to use a utility class on the client-side, to recall the relevant method repeatedly until the required Collection size is received. A more elegant approach to this problem might be considered in any improvements to the existing AfterInvocationProviders, or any new implementations thereof.
Ben
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
