Daniel Simms wrote:
You know how callers to radio shows say "Hi, I'm a long time listener but
a first time caller and I love your show."? This is like that for me.
Anyway...
Has anyone already handled a situation where domain objects being acted
upon are identified by id number (or at least something where getClass()
can't work). Let's just suppose it's a good idea otherwise to pass in id
instead of some less opaque object since I can't necessarily control that
interface.
No? I'm imaging whipping up a new voter that is told per-method how to
grok the identifier (instead of looking for the first instance of some
class). I think it would be wired up like this:
Hi Daniel
Yes, you're right. If you cannot control the interface of the
invocation, so say you have a public User getUser(Integer id), the
standard ACL classes (or, more specifically, BasicAclEntryVoter) will
not be of great help to you as it cannot obtain the AclEntry[]s for the
Integer on before() stage of the interception. Now, in this particular
case you could avoid the problem as you could use
BasicAclEntryAfterInvocationProvider to work with the returned User,
which could have the AclEntry[]s obtained and an appropriate
AccessDeniedException thrown. If the method did something like delete
the user, it still would be OK as the transaction demarcation on the
method should cause a rollback on the AccessDeniedException.
So the only time you'd really need to do something like your example is
if the signature was perhaps public void deleteUser(Integer id). In this
case you would need to write a custom AccessDecisionVoter. The actual
implementation could be approached in two distinct ways:
1. Have separate MyAccessDecisionVoter beans for each possible method.
Each bean would be wired as per standard Spring IoC to respond to a
particular configuration attribute that was expressed via the
MethodSecurityInterceptor.objectDefinitionSource. This is the simplest
conceptually to do, but will cause the most XML.
2. Have a single MyAccessDecisionVoter which can introspect the
MethodInvocation to determine the method being invoked. I think your
example was going along this path, which is certainly the more elegant.
A PropertyEditor would be used to convert a method signature into either
a simplified version of the domain object instance (ie create the class,
assign it the ID, then present it to the AccessDecisionManager) or
create an AclObjectIdentity that you can subsequently pass to a
BasicAclDao and walk the inheritance tree to compute the effective ACLs.
HTH
Ben
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
