If you just need access to the parameters from the action, you can use:
String resource =
invocation.getProxy().getConfig().getParams().get("AuthoritationInterceptor.resource");
I've used this several times to get parameters from the configuration, but I
usually put the parameters on the action instead of on the interceptor since
I consider them resources of the action invocation. I don't know if this
would also access the interceptor params or not. I would go with something
more like:
[...]
<action name="Dashboard" class="com.test.action.
>
> Dashboard">
> <interceptor-ref name="mvcStack"/>
> <param name="AuthoritationInterceptor.resource">Eco</param>
> <result name="MenuGestor" type="tiles">MenuGestor</result>
> <result name="MenuBanquero" type="tiles">MenuBanquero</result>
> <result name="MenuCliente" type="tiles" >MenuCliente</result>
> </action>
> [...]
>
(*Chris*)
On Mon, Dec 13, 2010 at 9:05 PM, JOSE L MARTINEZ-AVIAL <[email protected]>wrote:
> 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 <[email protected]>
>
> > 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" <[email protected]>
> 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 <[email protected]>
> >
> >
> > > I think you don't need this bothering job.
> > >
> > > You can:
> > >
> > > (1)Define some properties in your bas...
> >
>
