A few years ago, huh? You make it seem like such an archaic approach :) My question, I guess using a servlet/interceptor to do the same as this abstract class would conform more with the 'accepted' methodology? (I did play around with a servlet, but couldn't get it to redirect correct - I admit I haven't looked into Interceptors too deeply.)
-----Original Message----- From: Wes Wannemacher [mailto:w...@wantii.com] Sent: Thursday, August 20, 2009 8:11 PM To: Struts Users Mailing List Subject: Re: Struts2 with Authentication & Security I used this same approach for an app I worked on a few years ago. There is nothing wrong, in fact its simplicity is a bit of an advantage. If you can fit your needs into this type of setup then you will probably be happy that it is so easy to follow. On 8/20/09, Lee Clemens <j...@leeclemens.net> wrote: > This may not be perfect, and I welcome any criticism to this approach: > > abstract class extends ActionSupport which overrides execute() to > authenticate requests and then return a call to abstract method, say, > doAction(), or error if they are not authenticated/timed out. > > Each action which needs to be protected simply extends the above abstract > class and implements doAction(), just as you would normally override > execute(). Make execute() final in the abstract class... > > Add another abstract method to get a group authentication level (implemented > by each action's class) and you have a fairly robust and straightforward > authentication scheme, IMHO > > With proper negative testing, you can be certain any developer didn't forget > to extend/implement the 'security' action for any given action that should > be restricted >[snip] --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
