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]

Reply via email to