Article:		Extending Struts
Subject:		customizing the default requestprocessor
Date:		2005-01-22 05:33:31
From:		madhavim
In the example provided the customization has been done to incoporate logic to ensure the user is logged in before performing an action. This can alternatively be achieved by just extending org.apache.struts.action.Action and providing for the check in the execute method. Can you point out the disadvantages in doing so ?

Showing messages 1 through 2 of 2.

• customizing the default requestprocessor
  2005-01-24 00:01:53  SunilPatil [Reply | View]
  
  
  I think security is something which should be applied at application level.
  Yes you can check security in execute() method of your Action Class but then you have to copy+paste same code in every Action class which may not be very good thing.
  You can have separate class containing security code and call it from Action class but what if you forgot to call that method from one of your Action class.This type of bug would be very hard to find.
  Also waiting to check if user has rights to perform this action till Action class execute() method means you will have to execute business logic(validation) in your ActionForm class even if user is not allowed to call that Action.
  
  Sunil
• customizing the default requestprocessor
  2005-01-24 09:48:06  madhavim [Reply | View]
  
  
  I think the last point is a very valid one.
  
  Regarding the others, we could write a BaseAction class in which we can put the security logic along with some other common features and have each action class extending this BaseAction class. This would avoid the copy/paste, need for a seperate class and ensuring it is called etc.