I know that the inteceptor knows which action is invoked. I just don't want it to need to be aware of that. That's why I assigned a resource for each action, using a parameter in the definition of the action:
[...] <action name="Dashboard" class="com.test.action.Dashboard"> <interceptor-ref name="mvcStack"> <param name="AuthoritationInterceptor.resource">Eco</param> </interceptor-ref> <result name="MenuGestor" type="tiles">MenuGestor</result> <result name="MenuBanquero" type="tiles">MenuBanquero</result> <result name="MenuCliente" type="tiles" >MenuCliente</result> </action> [...] I could implement an interface for the action, but that would require defining an interface for each rule(since each rule needs different parameters). The second options is valid, but I like the idea of just declaring the getXXX method in the rule, and having the framework do the work for me(mostly, the type-conversion). What do you think? 2010/12/13 Maurizio Cucchiara <maurizio.cucchi...@gmail.com> > Ok, now it's definitively clear. > First every interceptor knows exactly which action is invoked through > action > invocation. > With that said your action could implement (1) your custom interface or (2) > a generic Request Aware interface in order to retrieve request parameters. > Does this answer your question? > > Maurizio Cucchiara > > Il giorno 14/dic/2010 03.27, "JOSE L MARTINEZ-AVIAL" <jlm...@gmail.com> ha > scritto: > Hi Maurizio, Li, > Thanks for your suggestion, but the problem with the approaches you > suggested is that they link the security rules too much to the actions. We > want to be as abstract as possible. For that, we have developed the > following implementation: > > We created some entities called SecurityResource which represent a set of > possible user actions. For example, we can have a SecurityResource called > SeeCustomer, that would be applied to any request related with seeing a > customer, or a SecurityResource called ModifyOwnProfile, used to filter any > action related to the modification of the profile. Every Action (unless it > is public) in the system is associated to a resource. > > We have also define some entities called SecurityAssert. A SecurityAssert > is a rule that checks some conditions, and returns true or false. They are > implemented through classes that implement a specific interface. For each > SecurityResource we have a list of SecurityAsserts that need to be > validated. So our security definition look as follows: > > <security-assert-definition name="SecurityAssertHasRole" > class="com.test.rules.SecurityAssertHasRole"> > <description>Regla de seguridad para comprobar si un usuario > tiene un rol</description> > </security-assert-definition> > > <security-assert-definition name="SecurityAssertDistributionList" > class="com.test.rules.SecurityAssertDistributionList"> > <description>Regla de seguridad para comprobar si un usuario > puede acceder a las listas de distribucion</description> > </security-assert-definition> > > <security-resource name="Eco"> > <security-assert-ref name="SecurityAssertHasRole" > character="mandatory"> > <parameter name="allowedRoles"> > <value>Role1</value> > <value>Role2</value> > <value>Role3</value> > </parameter> > </security-assert-ref> > </security-resource> > > Some of the rules need information from the request(customer number, for > example). In an ideal world the interceptor should not know anything about > the action it is trying to check. It should only invoke the rules, and > check > their results. So I(the interceptor) should to be able to pass parameters > from the request to the rule without actually having to know anything about > the request or the rules. Maybe the approach is complex, but we are > planning > to have some hundredths of actions, and be able to be as granular and > modular as possible with respect to security. Any ideas? > > thanks > > JL > > 2010/12/12 Li Ying <liying.cn.2...@gmail.com> > > > > I think you don't need this bothering job. > > > > You can: > > > > (1)Define some properties in your bas... >