I know that Spring Security (ACEGI) gets a lot of publicity, but there are other alternatives out there too. Last year I implemented a struts2 based system using Apache Shiro (formerly jsecurity), and found it very easy to learn an implement. On their website, http://cwiki.apache.org/SHIRO/ they have lots of documentation and examples.
Todd Kofford tkoff...@ku.edu University of Kansas - IT "the continuum transfunctioner is a very mysterious and powerful device and it's mystery is only exceeded by it's power" -----Original Message----- From: Paweł Wielgus [mailto:poulw...@gmail.com] Sent: Friday, August 21, 2009 7:10 AM To: Struts Users Mailing List Subject: Re: Struts2 with Authentication & Security Hi all, "a few years ago" means also that this solution still works. But from my point of view, inteceptor might be better if You are in a situation where You are not the only programmer or You are laizy and have bad memory - just like me. If so read this: http://poulwiel.blogspot.com/2009/01/intercepting-all-actions-inside-my-app.html Or use Spring Security (ACEGI). Best greetings, Paweł Wielgus. 2009/8/21 Lee Clemens <j...@leeclemens.net>: > 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 > > --------------------------------------------------------------------- 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
