Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of thechrispratt@gmail.com
 designates 209.85.161.54 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=YRr0wVSdxGxI197lL7X/RtVJmEohUEaSvGDiXgG9C/aTzXigedbq2MIQQDIFzZImUb
         36JxwR5B9W6peIZmovxmmH2Rjg2e8vZSy8L7ayA790kw+cAfGZpRWvMCFUBkX9G7cY7C
         YjTPI8wT0h9uK9Nltl9jC6G50qQbHPW/gYgec=
MIME-Version: 1.0
In-Reply-To: <AANLkTimcLn7NBmKVQWOZBok8rSHRzHnSEzVMBSdr+XW6@mail.gmail.com>
References: <F8B249376C1365488B8A4647BA28BFE603FE4E4F@miaexch.mia.usa.sinvest>
	<AANLkTim6rq4yhyTNzJtny3z0Pj36QYZawngu39yjUTAW@mail.gmail.com>
	<AANLkTinNUj7ZORq0VxBn5tVOT-XvOLJ4A0iuvqLJ2FzJ@mail.gmail.com>
	<AANLkTink=EGW4i8K+YPsLwpbt8sCXpL-oPV6tAJVj1Pb@mail.gmail.com>
	<AANLkTinPRjV5QQLaaqahWcsgUkVgCPRGZCACjiAFezir@mail.gmail.com>
	<AANLkTimcLn7NBmKVQWOZBok8rSHRzHnSEzVMBSdr+XW6@mail.gmail.com>
Date: Mon, 13 Dec 2010 22:09:55 -0800
Message-ID: <AANLkTin_Vn1APULUP4Y5Mf2KEkBXedhw51NPv96XhZ1d@mail.gmail.com>
Subject: Re: Invocation of type conversion manually
From: Chris Pratt <thechrispratt@gmail.com>
To: Struts Users Mailing List <user@struts.apache.org>
Content-Type: multipart/alternative; boundary=001636c5b588634b34049758abaf

--001636c5b588634b34049758abaf
Content-Type: text/plain; charset=ISO-8859-1

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

--001636c5b588634b34049758abaf--