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 > > -----Original Message----- > From: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com] > Sent: Thursday, August 20, 2009 4:25 PM > To: user@struts.apache.org > Subject: Struts2 with Authentication & Security > > > I am currently preparing the steps to port a legacy Struts1 application > to Struts2. The rewrite of the web application also includes a > transition from Tiles to Sitemesh along with the introduction of the > Spring and Hibernate frameworks. > > The authentication and security model used in the Struts1 application > was very simple and one of the pitfalls resulted in lack of overall > flexibility and ease of managing user roles and permissions. One of the > biggest goals of this rewrite process is to really spend a good chunk of > time looking at alternatives that make the most sense for what we're > trying to accomplish. > > The application is mainly a query-based tool for reporting a wide range > of data to a very large end user community. There are also > possibilities for gathering data from this user community and storing it > depending on specific business case needs. Since the user community > could span users that are customers, to in-house end users, site/local > management, and upper executive management, the options and data > presented to these users will need to vary. > > Is there any internal way within Struts2 that is recommended over > another to embed logic to support per-action/page security? Is there an > internal way to insure that the user is authenticated prior to servicing > the request? > > I've read about Interceptors versus using something like JAAS. Are > there benefits of one over another? I'd rather not introduce a new > framework atop of Spring and Hibernate given we're moving from Struts1 > to Struts2 and Tiles to Sitemesh. It is a learning curve and adding new > frameworks continues to agitate the issue. > > Thanks for everyone's feedback. > Chris > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
