On 5/9/05, Benedict, Paul C <[EMAIL PROTECTED]> wrote:
> Craig,
> 
> I found out the hard way that URL patterns are not regular expressions. Why
> the limitation? My solution (which I did not implement) was to attach a
> filter to "/" and then run regular expression patterns on the URI.
> 

A historical accident, really.  The supported patterns were first
defined back in Servlet 2.0 (late 1990s sometime), *long* before there
was efficient regular expression processing in Java code -- and
they've never been updated in any subsequent servlet spec.

> Paul

Craig

> 
> -----Original Message-----
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 09, 2005 3:39 PM
> To: Struts Users Mailing List; Jeff Beal
> Subject: Re: Sample Code for Desclarative Security in Struts
> 
> On 5/9/05, Jeff Beal <[EMAIL PROTECTED]> wrote:
> > Solution 1: I don't believe there has to be any correlation between
> > your web-resource-collections in your security-constraints and your
> > servlet-mappings in web.xml.  It seems to be perfectly valid to map
> > *.do to ActionServlet (a single servlet-mapping) and have /admin/*.do
> > and /user/*.do handled by two different security constraints.
> 
> There's an important detail necessary to get this right.
> 
> URL patterns in web.xml are not fully flexible regular expressions.
> What you would do in this case is map Struts to "*.do", and have web
> resource collection constraints on "/admin/*" and "/user/*".  That
> would have the effect of protecting the admin and user actions (as
> well as anything else in those two subdirectories), while allowing
> unauthenticated access to all the other actions.
> 
> >
> > Solution 2: You also have the option (since Struts 1.1) to declare
> > your security inside of struts-config.xml.  The roles attribute of the
> > action element lists the set of roles that you are allowing to access
> > a particular action.
> 
> This is likely to be better if you want to protect just a few actions,
> instead of groups of them.  In the latter case, Solution 1 is likely
> to work better.
> 
> >
> > -- Jeff
> >
> 
> Craig
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ------------------------------------------------------------------------------
> 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) 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]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to