You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jose Luis Martinez Avial <jl...@pb-santander.com> on 2010/12/10 01:27:15 UTC
Invocation of type conversion manually
Hello all,
I'm using Struts 2..1.8.1 for an application. To integrate the
security in the application we have developed an interceptor that
intercepts every request and checks a list of rules(implemented as
classes) to know if the user is allowed to execute the action. The
validation should be dinamic, so the rules should be able to receive
information from the request. What I would like to do is to use Struts'
mechanism to process, parse and type-convert the request's parameters
to do that. So I would invocate the Struts' conversion over the classes
implementing the rules, and set the parameters in the rules, the same
way Struts does with the actions. I've tried looking at the code, but
I'm a bit lost. Can somebody give some orientation on how to invoke the
conversion?
Thanks
JL
Internet communications are not secure and therefore Banco
Santander International does not accept legal responsibility for
the contents of this message. Any views or opinions presented
are
solely those of the author and do not necessarily represent those
of Banco Santander International unless otherwise specifically
stated.
Las comunicaciones via Internet no son seguras y por lo tanto
Banco Santander International no asume responsabilidad legal
ni
de ningun otro tipo por el contenido de este mensaje. Cualquier
opinion transmitida pertenece unicamente al autor y no
necesariamente representa la opinion del Banco Santander
International a no ser que este expresamente detallado.
Re: Invocation of type conversion manually
Posted by JOSE L MARTINEZ-AVIAL <jl...@gmail.com>.
I used interfaces to get this to work. So every Security Assert defines also
an interface that should be implemented by the Actions. It took a while, but
it's working now. Thanks for the advices.
2010/12/14 Chris Pratt <th...@gmail.com>
> 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 <ma...@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 <li...@gmail.com>
> > >
> > >
> > > > I think you don't need this bothering job.
> > > >
> > > > You can:
> > > >
> > > > (1)Define some properties in your bas...
> > >
> >
>
Re: Invocation of type conversion manually
Posted by Chris Pratt <th...@gmail.com>.
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 <jl...@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 <ma...@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" <jl...@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 <li...@gmail.com>
> >
> >
> > > I think you don't need this bothering job.
> > >
> > > You can:
> > >
> > > (1)Define some properties in your bas...
> >
>
Re: Invocation of type conversion manually
Posted by JOSE L MARTINEZ-AVIAL <jl...@gmail.com>.
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 <ma...@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" <jl...@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 <li...@gmail.com>
>
>
> > I think you don't need this bothering job.
> >
> > You can:
> >
> > (1)Define some properties in your bas...
>
Re: Invocation of type conversion manually
Posted by Maurizio Cucchiara <ma...@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" <jl...@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 <li...@gmail.com>
> I think you don't need this bothering job.
>
> You can:
>
> (1)Define some properties in your bas...
Re: Invocation of type conversion manually
Posted by JOSE L MARTINEZ-AVIAL <jl...@gmail.com>.
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 <li...@gmail.com>
> I think you don't need this bothering job.
>
> You can:
>
> (1)Define some properties in your base class of all your action classes.
> (2)Use these properties to capture data from the request.
> (3)Run your interceptor AFTER the interceptors of struts2.
> But BEFORE the execution of the Action class
>
> So,
> The interceptors of struts2 will do the data-conversion for you.
> Your interceptor can simply extract parameters all you need from the
> Action instance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Invocation of type conversion manually
Posted by Li Ying <li...@gmail.com>.
I think you don't need this bothering job.
You can:
(1)Define some properties in your base class of all your action classes.
(2)Use these properties to capture data from the request.
(3)Run your interceptor AFTER the interceptors of struts2.
But BEFORE the execution of the Action class
So,
The interceptors of struts2 will do the data-conversion for you.
Your interceptor can simply extract parameters all you need from the
Action instance.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Invocation of type conversion manually
Posted by Maurizio Cucchiara <ma...@gmail.com>.
2010/12/10 Jose Luis Martinez Avial <jl...@pb-santander.com>:
>The
> validation should be dinamic, so the rules should be able to receive
> information from the request.
Basing Rule Access Control on request's parameters might induce
security flow risks.
> What I would like to do is to use Struts'
> mechanism to process, parse and type-convert the request's parameters
> to do that. So I would invocate the Struts' conversion over the classes
> implementing the rules, and set the parameters in the rules, the same
> way Struts does with the actions. I've tried looking at the code, but
> I'm a bit lost. Can somebody give some orientation on how to invoke the
> conversion?
What about using an abstract BaseAction with your rule bean declared inside?
--
Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org