Pattern sorting problem (BUG?) Re: 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