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...
>
