Re: Pattern sorting problem (BUG?) Re: Regex use

Wonderful!

I'm looking forward to it.

I tried to look into throwing exceptions in SecurityConfig when files
aren't found, but most errors seem to be related to regular expression
matching, so I figure I should wait for your changes that remove regex
stuff for now.


rob


On Thu, 2 Jan 2003, Max Cooper wrote:

> Rob,
>
> Well, that's another bug. I just wrote it up in the bug tracking system on
> SourceForge and then promptly fixed it in CVS. It is fixed right now in CVS.
> All I did was jostle the values of the pattern type constants to put
> EXACT_TYPE first.
>
> Note that the configuration in CVS currently uses the Jakarta-ORO regex
> package, but the upcoming release will not. There will be an (overdue)
> release in the next day or two that fixes a lot of the bugs found over the
> past few months. I will post an announcement to this list when it is ready.
> The code in the CVS repository should be functional most of the time (except
> for when I do sloppy multi-file commits, etc.).
>
> -Max
>
> ----- Original Message -----
> From: "Robert Ellis Parrott" <[email protected]>
> To: "Max Cooper" <[email protected]>
> Cc: <securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> Sent: Thursday, January 02, 2003 8:57 AM
> Subject: Pattern sorting problem (BUG?) Re: [securityfilter-user] Regex use
>
>
> >
> > I gave your suggestion below for ordering url patterns a try, and I
> > believe that there is some bug in the code at this point. This is all
> > based on latest CVS.
> >
> > The security constraints are as follows:
> >
> > <!-- Default configuration: secure all to begin with -->
> >
> > <security-constraint>
> >    <web-resource-collection>
> >       <web-resource-name>Basic Secured resources</web-resource-name>
> >       <url-pattern>/*</url-pattern>
> >    </web-resource-collection>
> >    <auth-constraint>
> >      <role-name>member</role-name>
> >    </auth-constraint>
> > </security-constraint>
> >
> > <security-constraint>
> >    <web-resource-collection>
> >       <web-resource-name>Public</web-resource-name>
> >       <url-pattern>/index.jsp</url-pattern>
> >       <url-pattern>/public-index.jsp</url-pattern>
> >       <url-pattern>/public/*</url-pattern>
> >    </web-resource-collection>
> > </security-constraint>
> >
> >
> >
> > I inserted some debugging code just after the sort in
> > SecurityFilter.init(); the output is as follows:
> >
> > SecurityFilter.init: ordered patterns:
> >   1) /public/*         (order in config file: 4  type: 1  len: 1 )
> >   2) /*                (order in config file: 1  type: 1  len: 0 )
> >   3) /index.jsp        (order in config file: 2  type: 3  len: 0 )
> >   4) /public-index.jsp (order in config file: 3  type: 3  len: 0 )
> >
> >
> > According to your statements below, the type 3 patterns should come first.
> >
> > Is this correct?
> >
> > For reference, the code inserted right after the
> > Collections.sort(patternList);
> > is:
> >
> > System.out.println("SecurityFilter.init: ordered patterns:");
> > order = 1;
> > for (Iterator i = patternList.iterator(); i.hasNext();) {
> > URLPattern pat =  (URLPattern) i.next();
> > System.out.println("  "+order+") "+pat.getPattern() +
> >                 " (order in config file: "+pat.getOrder()+
> >                 "  type: "+pat.getPatternType()+"  len:
> >                         "+pat.getPathLength()+" )");
> > order++;
> > }
> >
> >
> >
> >
> > On Wed, 1 Jan 2003, Max Cooper wrote:
> >
> > > Rob,
> > >
> > > I am in the process of converting SecurityFilter to the no-regex scheme
> > > recently submitted by Chris N. in some messages to this list. This
> scheme
> > > works for the pattern language defined in the Servlet spec, which is the
> > > document that guides development on SecurityFilter.
> > >
> > > >From your description, it sounds like you should be able to do what you
> need
> > > with the standard patterns. Here's an example (that should work with the
> > > current implementation; replace the '/*' pattern with '/' when the
> default
> > > servlet support is fixed/added in SecurityFilter):
> > >
> > >    <security-constraint>
> > >       <web-resource-collection>
> > >          <web-resource-name>Secure</web-resource-name>
> > >          <url-pattern>/*</url-pattern>
> > >       </web-resource-collection>
> > >       <auth-constraint>
> > >          <role-name>role_that_all_authenticated_users_have</role-name>
> > >       </auth-constraint>
> > >    </security-constraint>
> > >
> > >    <security-constraint>
> > >       <web-resource-collection>
> > >          <web-resource-name>Public</web-resource-name>
> > >          <url-pattern>/index.jsp</url-pattern>
> > >          <url-pattern>/public/*</url-pattern>
> > >       </web-resource-collection>
> > >    </security-constraint>
> > >
> > > The order of pattern matching should be:
> > >
> > > /index.jsp (EXACT_TYPE)
> > > /public/* (PATH_TYPE, comes before /* because it has more path elements
> than
> > > than /*)
> > > /*
> > >
> > > So visitors should be able to get to the index.jsp page and anything in
> > > /public without being authenticated (since no auth-constraints are set
> for
> > > those patterns). Everything else will require the user to be
> authenticated
> > > and in the role_that_all_authenticated_users_have role to gain access.
> If
> > > the configuration above doesn't work as you need it to, please post
> about
> > > what doesn't seem to work. It is off-the-cuff rather than tested, so it
> > > might not be quite right.
> > >
> > > I am interested in the possibilities of supporting more advanced
> security
> > > based on URL patterns, but spec compliance is the primary goal. Perhaps
> a
> > > regex system will be added back in as "extended features" are desired.
> Some
> > > matching based on a more powerful pattern language, perhaps including
> the
> > > query string, with plug-ins for determining access would be a useful way
> to
> > > separate security processing from functional processing, for instance.
> > > Imagine a mapping of the pattern /accountDetails.do* to a piece of code
> > > (specfied by a class name that implements a security checking interface)
> > > that will take the URL with the query string (or just the request) and
> then
> > > decide if access should be allowed or denied. The check would be by who
> owns
> > > the account rather than roles in this case (though normal role-based
> > > patterns may be processed first). Any persistent objects that need to be
> > > loaded for the security check could be passed via request attributes to
> the
> > > functional level (with some pain of coupling the security and functional
> > > layers), and perhaps different responses could be supported for error
> > > ("account does not exist") versus "access denied" cases, if that would
> be
> > > useful. Anyway, this example doesn't require regex stuff, but perhaps as
> we
> > > flesh out some more requirements, regex support will be needed again. It
> > > would probably be best to offer these extended features as a separate
> filter
> > > for use with container-managed authentication for portability, though
> > > perhaps there is something to gain by having SecurityFilter support both
> the
> > > container-clone stuff and the extended features. These are just ideas at
> > > this point with no code to speak of at this time.
> > >
> > > -Max
> > >
> > > ----- Original Message -----
> > > From: "Robert Ellis Parrott" <[email protected]>
> > > To: <securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> > > Sent: Tuesday, December 31, 2002 2:38 PM
> > > Subject: [securityfilter-user] Regex use
> > >
> > >
> > > >
> > > > I looked into SecurityFilter originally because I needed to protect
> > > > almost all resources within a webapp except for a few that represent a
> > > > front door view, and login page components, and I thought that regex
> > > > functionality could do this for me. I had hoped that I could specify a
> > > > regex in the config file, since they are so powerful.
> > > >
> > > > However, the way that SecurityFilter works is that it assumes a
> > > > significantly simpler URL Pattern in the config file, so that my regex
> > > > expressions are mauled up.
> > > >
> > > > What I had wanted to do was match almost every URL expect those under
> a
> > > > /public directory, and one index.jsp page, so that instead of manually
> > > > securing a resource, the default is that it's secure and you have to
> > > > manually unsecure it.
> > > >
> > > > I propose that true and untampered regex functionality be included in
> the
> > > > matching code; this is a small modification, but allows for much more
> > > > powerful matching ability. I've made a modification to URLPattern to
> > > > accomplish this; basically, prefixing a URLPattern value by "RE:"
> tells
> > > > URLPattern to interpret it as a true regular expression, and compiler
> it
> > > > as is. I don't think that the string "RE:" will clash with any URL
> > > > pattern.
> > > >
> > > > And as for the suggestions that regex capability be removed, I agree
> that
> > > > it might be removed for some pattern types, but should still be
> available,
> > > > at least for this functionality.
> > > >
> > > > rob
> > > >
> > > >
> > > >
> > > >
> > >
> patch: ---------------------------------------------------------------------
> > > >
> > > > Index: URLPattern.java
> > > > ===================================================================
> > > > RCS file:
> > > >
> > >
> /cvsroot/securityfilter/securityfilter/src/share/org/securityfilter/filter/U
> > > RLPattern.java,v
> > > > retrieving revision 1.1
> > > > diff -r1.1 URLPattern.java
> > > > 85a86,90
> > > > > /**
> > > > > * Pattern type for patterns that are regular expressions themselves;
> > > > > * they are preceeded by "RE:".
> > > > > */
> > > > >    public static final int RE_TYPE = 4;
> > > > 189c194,197
> > > > <       if (pattern.startsWith("*.")) {
> > > > ---
> > > > >
> > > > >   if (pattern.startsWith("RE:") ) {
> > > > >          patternType = URLPattern.RE_TYPE;
> > > > >       } else if (pattern.startsWith("*.")) {
> > > > 251a260,263
> > > > >
> > > > >   // however, if RE_TYPE, assume that input was valid RE, and just
> > > remove "RE:" prefix
> > > > >   if (patternType == RE_TYPE) { convertedPattern =
> > > pattern.substring(3);}
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > securityfilter-user mailing list
> > > > securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > > https://lists.sourceforge.net/lists/listinfo/securityfilter-user
> > > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > securityfilter-user mailing list
> > securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/securityfilter-user
> >
>
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf