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

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