Re: Regex use

Thanx for the prompt response.

I'll give your suggestion a try.

I do still think that you should consider including regular expression
matching functionality in your project; it would just add that much value,
and you've already got it working at this point. For the time being you
might want to just include your past work as is without a plugin
mechanism. The "RE:" prefix mechanism would be an easy way to save this
functionality and work from being wasted, and would break the standard
specs in an essentially trivial and  inconsequential manner.

It was the claim of regular expression matching that attracted me to your
work, and I would conjecture that I'm not the only such person who would
find it attractive.

Anyway, I look forward to the next release. Are your changes in CVS, and
how far along? I'd like to pull them down and try to use them when they
are in working order.


I also have a couple small complaints about configuration handling: When I
first compiled the code, I put it in the the WEB-INF/classes directory,
and got a null pointer from Tomcat and a completely irrelevant line
number. The upshot is that it couldn't find the DTD, even though I
specified no validation. Should it load the DTD even if no validation is
desired.

This, and forgetting to copy over over the security-config.xml cost me
about 1-2 hours tracking down the error in SecurityConfig. While this
isn't a bug, it ain't user-friendly behavior to throw a NullPointer
exception for a missing config file.

I would suggest an exception class for configuration, and throwing it with
appropriate message when these things fail, so that you direct the user
right to the root cause of the error. Should be 15 minutes of work.


Thanx again for your effort and project,


rob



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