You don't need to add "additional XML elements to the Action in the
struts-config.xml" to use a custom ActionMapping

If you create your own custom ActionMapping with an additional
"securityLevel" property:


public class MyActionMapping extends ActionMapping {

   protected String securityLevel;

   public void setSecurityLevel(String securityLevel) {
      this.securityLevel = securityLevel;
   }

   public String getSecurityLevel() {
       return securityLevel;
   }

}

The in your struts-config.xml you can configure struts to use your custom
mapping using the type on the <action-mappings> element and set the new
attribute for one of your actions using <set-property>:

<action-mappings type="mypackage.MyActionMapping ">

        <action path="myPathValue" name="myForm">
            <set-property property="securityLevel " value="high"/>
        </action>

</action-mappings>


Niall

----- Original Message ----- 
From: "Josh Holtzman" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Saturday, April 17, 2004 10:41 PM
Subject: RE: Struts Application Security within the Controller Layer


> Joe,
>
> Your suggestion sounds interesting, but I'm not sure if I fully understand
> it.
>
> Correct me if I'm wrong.
>
> You suggest extending the ActionMapping class and adding the fields to
this
> class that I will need for checking the user group that may access this
> path/resource.  Let's say this is a simple application, and there is an
> integer or string that is stored, identifying the access level to this
> resource.  So, when this class is built, would it represent an action
within
> my struts config file, and with the changes permit me to somehow specify
the
> permission level that has access to the action?
>
> I'm a little confused about the "SecureActionMapping" interface you
> mentioned.
>
> However, if what you are suggesting is that the extended ActionMapping
would
> now contain the role that has access to this action, I could then extend
the
> RequestProcessor to inspect the permitted user group that is stored in the
> new ActionMapping class, and compare it to the permission level stored in
> the User's session.  If these don't agree with one another, the user does
> not have access to the path/resource, and will be directed to an error
page.
>
> Is this what you had in mind?  If so, I'm still a little confused about
how
> to extend the ActionMapping so it would contain the correct permission
level
> info for access to the resource.  How/where would this information be
> configured.  I think you might be suggesting additional XML elements or
> attributes may be added to the Action element in the StrutsConfig file,
but
> I'm not sure.
>
> Please let me know your thoughts.  Everyone else is also free to comment.
>
> Regards,
>
> Josh
>
> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 16, 2004 9:07 AM
> To: Struts Users Mailing List
> Subject: RE: Struts Application Security within the Controller Layer
>
> The way to configure this flexibly for each action would be to define
> an extension of ActionMapping that was a bean with whatever config
> properties you need (for instance, a role or list of roles permitted
> to access the action.)  Of course, since each path gets only one
> ActionMapping, you may need to use a "SecureActionMapping" interface
> that you could implement with various mapping classes.  (It seems to
> take Struts users a while to get into the idea of using ActionMapping
> to provide extended configuration information to an Action class, but
> it can be a very nice way to avoid re-coding the same logic over and
> over.)
>
> Once you have this, you could either find another spot in the request
> processor to enforce this logic (very easy with a chainable
> processor, of course), or use a "SecureAction" base class from which
> you extend for any paths which must be controlled, which would do
> authorization before passing control to the subclass.
>
> Joe
>
>
> >I'll look into the "ComposableRequestProcessor" for future projects.
This
> >seems like it could be a very powerful feature, if used correctly.
> >
> >Since we are on the subject of Control and security, let me throw in
> another
> >question.
> >
> >My application has three different user permission levels.
> >1) User
> >3) Super User
> >2) Admin
> >
> >Each account in the DATABASE is classified with one of these permission
> >levels.
> >
> >I want to also inspect each request before an Action is dispatched to
> >confirm that the User should be granted access to execute the Action.
> >
> >At first thought, it seems that I cannot use the processRoles() feature
of
> >the RequestProcessor, because my permission levels are not stored into
the
> >config file, but rather in the database.  Or should I say, I cannot take
> >this approach without overriding this method (which may be a solid
> >approach.. but I haven't thought it out much. I imagine this would
require
> a
> >way for me to map each action with the correct access groups).
> >
> >I could put this logic into each Action class, but, for obvious reasons,
> >this will be a maintenance nightmare.
> >
> >Can anyone offer any suggestions on these or other approaches?
> >
> >Your assistance is greatly appreciated as it always is.
>
> -- 
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>        "Imagine if every Thursday your shoes exploded if you tied them
> the usual way.  This happens to us all the time with computers, and
> nobody thinks of complaining."
>              -- Jef Raskin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to