Raible's Wiki

Raible Designs
Wiki Home
News
Recent Changes

AppFuse

Homepage
  - Korean
  - Chinese
  - Italian
  - Japanese

QuickStart Guide
  - Chinese
  - French
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish
  - Japanese

User Guide
  - Korean
  - Chinese

Tutorials
  - Chinese
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish

FAQ
  - Korean

Latest Downloads

Other Applications

Struts Resume
Security Example
Struts Menu

Set your name in
UserPreferences


Referenced by
Main
Mojavelinux




JSPWiki v2.2.33

[RSS]


Hide Menu

SecuringDispatchAction


This is version 3. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]


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. Consider the following action mapping configuration.

<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 the following?

  • /RetrieveUser?method=add

You guessed it, there is no check because the configuration doesn't allow for this distinction. If you want to believe it works (and hope you don't have a malicious user), 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 mappings.

<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"/>

A subtle difference indeed. In my BaseAction, which extends DispatchAction, I parse the parameter attribute 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 option becomes the default for that action mapping. 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! If you leave off the second part of the parameter it just behaves as it would normally.

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

~ mojavelinux



Go to top   More info...   Attach file...
This particular version was published on 06-Nov-2006 13:52:36 MST by Mojavelinux.