Re: Regex use

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