for users of DispatchAction, a security/validation idea

[Dan Allen <da...@mojavelinux.com>]

For those of you who are using DispatchAction and are having difficulty with
the validation framework, I have an idea to propose.  Up to this point the two
practices seemed to conflict, namely because the validator cannot distinguish
between

EditUser?method=save
EditUser?method=delete
EditUser?method=retrieve

After beating my head and pulling my hair I came up with a sweet solution.
Instead of setting up your action as

<action
    path="/RetrieveUser"
    name="userForm"
    type="org.webapp.presentation.users.actions.UserFormAction"
    parameter="method"
    validate="false"/>

<action
    path="/EditUser"
    name="userForm"
    type="org.webapp.presentation.users.actions.UserFormAction"
    parameter="method"
    validate="true"
    input="userForm.page"/>

By splitting up the retrieve from the create, update, delete I have allowed two
different actions to use the same DispatchAction class. However, a problem
arises...what problem you ask?  Well, what stops a user from requesting

/RetrieveUser?method=add

???  Exactly, there is no check because the configuration doesn't allow for
this distinction.  If you want to believe it works, it looks good, but as soon
as you wake up from your day dream you realize that the extra action only adds
cosmetic protection against getting around the validator.

So, I came up with a solution. While my idea does not necessarily dictate a
patch to the struts framework, it certainly could be used in an application's
BaseAction class.

consider the following:

<action
    path="/RetrieveUser"
    name="userForm"
    type="org.webapp.presentation.users.actions.UserFormAction"
    parameter="method retrieve"
    validate="false"/>

<action
    path="/EditUser"
    name="userForm"
    type="org.webapp.presentation.users.actions.UserFormAction"
    parameter="method create,update,delete"
    validate="true"
    input="userForm.page"/>

Now, in my BaseAction, which extends DispatchAction, I parse the parameter and
check to see if the value of the parameter (the string before the space)
matches a value from my tokenized list of methods (which follow the space).
This way, you can limit the method values which can occur for an action which
uses DispatchAction.  Aha!  Now, you can use DispatchAction to organize your
classes, but have the same control as if you where using different classes for
each action....the perfect solution.  If a user tries to access

/RetrieveUser?method=add

I send them to the error.page global forward with an appropriate ActionError
message.

So one last question, what about unspecified?  What if, because the jsp
designer is lazy, you want more than one unspecified method, one for each
action mapping perhaps?  Easy, the first one becomes the default. This way you
use the syntax regardless, so if the user leaves off the method in RetrieveUser
such as

/RetrieveUser

it just goes to the retrieve method.  Now you can use DispatchAction for every
action!  No reason not to!  Tying the method names into the action mapping
makes a whole lot of sense to me, provides security, and can easily be
specified and created using xdoclet!

Hope that helps clear things up for some people.  Happy Struttin'

Dan

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
'One Microsoft Way' is more than just an address.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org