I'm sorry, I should have been more specific with my original question. I need to secure struts *.action URIs. Nothing else, be it by port, directory mapping, or context name. Right now. You see, my app supports adding users and changing their roles via web UI (hence the DB). It also supports adding sections and/or pages at run-time, which requires the capability to dynamically add new URI-role mappings.
For these reasons, container-managed security is out of the question. Recompiling, redeploying, and/or restarting are best avoided. This is what the current framework affords me. These are the reasons I was thinking app-managed security. The current framework uses a filter to do authentication & authorization validation. It throws typed exceptions which are handled via web.xml's error-page. I was having difficulty maintaining sessions during this error page redirection, which makes it difficult to maintain the originally-requested URL for redirection to upon successful login. Aside from that it works well. But I want to expand my skillset, so I can take this opportunity to work with Interceptors. Or Spring. Or something else, but these two seem to have more traction than anything else so that's probably where I'll land. -----Original Message----- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2008 9:54 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [S2] Interceptor question dave- which urls needs to be secured? Struts webapp? All the webapps of your container? everything under Port 80? take a look at http://www.devarticles.com/c/a/Java/Securing-Struts-Applications/ Martin ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Subject: [S2] Interceptor question > Date: Tue, 16 Sep 2008 16:37:26 -0400 > From: [EMAIL PROTECTED] > To: user@struts.apache.org; [EMAIL PROTECTED] > > I have a mature, home-grown database-backed authentication & > authorization framework. > It does not conform to JAAS or anything remotely similar. > I'd like to harness in a new struts2 site, because the core > functionality exists, it pre-populated, etc > > At a very high level, would I be able to get some advice on a path > forward: should I be thinking of a custom Interceptor, extending an > existing Interceptor, using Spring security, or something completely > different? > Thanks is advance, > -dave > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, > New Jersey, USA 08889), and/or its affiliates (which may be known > outside the United States as Merck Frosst, Merck Sharp & Dohme or > MSD and in Japan, as Banyu - direct contact information for affiliates is > available at http://www.merck.com/contact/contacts.html) that may be > confidential, proprietary copyrighted and/or legally privileged. It is > intended solely for the use of the individual or entity named on this > message. If you are not the intended recipient, and have received this > message in error, please notify us immediately by reply e-mail and > then delete it from your system. _________________________________________________________________ Want to do more with Windows Live? Learn "10 hidden secrets" from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cn s!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]