struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pratt <thechrispr...@gmail.com>
Subject Re: Invocation of type conversion manually
Date Tue, 14 Dec 2010 06:09:55 GMT
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 <jlmagc@gmail.com>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 <maurizio.cucchiara@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" <jlmagc@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.2010@gmail.com>
> >
> >
> > > I think you don't need this bothering job.
> > >
> > > You can:
> > >
> > > (1)Define some properties in your bas...
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message