You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by br...@paraware.com on 2003/02/11 21:47:26 UTC
ActionGuard tag
I've developed a tag that we think has some usefulness in the presentation
area. I am wondering if there is interest:
The tag basically is an actionGuard
<security:actionGuard actionPath="/remove/User"
securityHelper="securityHelper" condition="true">
Stuff that should only be seen if the user associated with this request is
on the role specified in the action mapping of the struts-config.xml file.
</security:actionGuard>
The security helper is an interface with methods similar to that of the
J2EE security: e.g. isUserInRole(), getRemoteUser(). The rational
behind this was that we were using a third party security mechanism that
we needed to adapt our code to.
We have a J2EESecurityAdapter that implements this interface and passes
requests on through.
The obvious benefit to this was that we could modify our roles in the
struts-config.xml file and then actions would magically appear/disappear
in our JSP.
If there is any interest in this for Struts, please let me know.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionGuard tag
Posted by br...@paraware.com.
The <logic:present> tag is more generic. If one only wants to hide
"content" that is not specific to action, but is only specific to role
then using the <logic:present> tag would be more suitable.
The <security:actionGuard> tag is geared toward actions. It does a lookup
of the roles from struts-config.xml by way of the actionPath (that is
defined in the action mapping as well). In addition, many situations call
for a different security process to be used (i.e. non J2EE), which I
presume was part of the rationale behind processRoles() method of the
RequestProcessor--the <security:actionGuard> accommodates this with the
actionhelper.
Specifying a "role" in an action is necessary as it prevents backdooring a
web-app. On many apps I prefer to not show the user actions I prefer to
The actionGuard simplifies the task and prevents the display of actions on
the front-end.
Brian
"Craig R. McClanahan" <cr...@apache.org> wrote on 02/11/2003 04:18:38
PM:
>
>
> On Tue, 11 Feb 2003 brian.bonner@paraware.com wrote:
>
> > Date: Tue, 11 Feb 2003 15:47:26 -0500
> > From: brian.bonner@paraware.com
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts-dev@jakarta.apache.org
> > Subject: ActionGuard tag
> >
> > I've developed a tag that we think has some usefulness in the
presentation
> > area. I am wondering if there is interest:
> >
> > The tag basically is an actionGuard
> >
> > <security:actionGuard actionPath="/remove/User"
> > securityHelper="securityHelper" condition="true">
> > Stuff that should only be seen if the user associated with this
request is
> > on the role specified in the action mapping of the struts-config.xml
file.
> > </security:actionGuard>
> >
> > The security helper is an interface with methods similar to that of
the
> > J2EE security: e.g. isUserInRole(), getRemoteUser(). The rational
> > behind this was that we were using a third party security mechanism
that
> > we needed to adapt our code to.
> >
> > We have a J2EESecurityAdapter that implements this interface and
passes
> > requests on through.
> >
> > The obvious benefit to this was that we could modify our roles in the
> > struts-config.xml file and then actions would magically
appear/disappear
> > in our JSP.
> >
>
> How does this compare to the (existing) facility of Struts to say
> something like this in a JSP page?
>
> <logic:present role="manager">
> ... show some stuff only managers should see ...
> </logic:present>
>
> Struts also lets you restrict actions to certain roles, by adding a
> "roles" attribute on the <action> element.
>
> > If there is any interest in this for Struts, please let me know.
> >
> > Brian
> >
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
Re: ActionGuard tag
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 11 Feb 2003 brian.bonner@paraware.com wrote:
> Date: Tue, 11 Feb 2003 15:47:26 -0500
> From: brian.bonner@paraware.com
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts-dev@jakarta.apache.org
> Subject: ActionGuard tag
>
> I've developed a tag that we think has some usefulness in the presentation
> area. I am wondering if there is interest:
>
> The tag basically is an actionGuard
>
> <security:actionGuard actionPath="/remove/User"
> securityHelper="securityHelper" condition="true">
> Stuff that should only be seen if the user associated with this request is
> on the role specified in the action mapping of the struts-config.xml file.
> </security:actionGuard>
>
> The security helper is an interface with methods similar to that of the
> J2EE security: e.g. isUserInRole(), getRemoteUser(). The rational
> behind this was that we were using a third party security mechanism that
> we needed to adapt our code to.
>
> We have a J2EESecurityAdapter that implements this interface and passes
> requests on through.
>
> The obvious benefit to this was that we could modify our roles in the
> struts-config.xml file and then actions would magically appear/disappear
> in our JSP.
>
How does this compare to the (existing) facility of Struts to say
something like this in a JSP page?
<logic:present role="manager">
... show some stuff only managers should see ...
</logic:present>
Struts also lets you restrict actions to certain roles, by adding a
"roles" attribute on the <action> element.
> If there is any interest in this for Struts, please let me know.
>
> Brian
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org