Re: Suggestions

> On Thu, Jan 02, 2003 at 04:35:59PM -0800, Max Cooper wrote:
> > Tomcat 4.1.18-LE-jdk14 is still broken.
>
> I don't understand how you can conclude this, in my tests it works and
> the bug report says as much. Do you have a simple piece of example code?

Here are the values returned by the various HttpServletRequest methods with
Tomcat 4.1.18-LE-jdk14 for my test request:

request.getRequestURI() = /securityfilter-example///////////index.jsp
request.getRequestURL() =
http://localhost:8080/securityfilter-example///////////index.jsp
request.getServletPath() = //////index.jsp

request.getServletPath() is the only one that is supposed to normalize the
URI according to the Javadoc, and it doesn't do a complete job in this case.
That would be a big hole, since requests for //showMeTheMoney.jsp will get
past SecurityFilter and show the page even if /showMeTheMoney.jsp is
protected.

>
> These results are fine, as long as WebLogic is not normalizing the URL
> to do security or servlet mappings. If that example actually returns the
> result of executing index.jsp, then WebLogic is broken (unsurprising).

Yes, WebLogic seems to do the normalization for getServletPath(). It would
be okay to omit the /+ trick and use getServletPath() to get the pattern
with WebLogic (6.1 SP2 at least). This seems to be the proper behavior to
me, but I don't want to make a hole for Tomcat users.

> > In light of this bug and the likelihood that other containers are
similarly
> > broken, I think it is best to keep the regex stuff in security filter at
> > this time for "multiple slash" matching. I've got to decide something to
get
> > the release ready, so this is it. The next release with have the
Jakarta-ORO
> > Perl5 pattern matching. That may change in the future, but I want to get
a
> > release out that has fixes for other bugs.
>
> Working around conformance bugs is going to keep you awake at
> nights. IMHO you'd be much better served by taking the high road and
> following the spec.

I rarely sleep anyway ;-), and it is not clear to me what the spec is in
this area. At this point, I'd rather be safe and get the other bug fixes in
for a release. I am certainly open to changes based on further
clarification, etc., but I want to get a release out with some of the other
bug fixes first. I had to make a decision to move forward for this release,
and my decision is to keep the Perl5 stuff for now. I like the idea of
eliminating the regex package dependency, but I don't feel comfortable with
doing it for this release.

> Another argument is: //foo//bar//baz.jsp is fine as a URL, and you could
> write security constraint in web.xml to protect //foo//*. It is all
> perfectly legal. By normalizing in the filter you're breaking the
> spec. Just my two cents.

Containers seem to serve a page/JSP/servlet no matter how many slashes are
in the URL. These will all get you to the same page:

/index.jsp
//index.jsp
:
////////////////////////////////////////////index.jsp
:
(add as many slashes as you want)/////////////////////////////////index.jsp

It is not practical or even possible to specify the securityfilter
url-patterns with all the possible numbers of slashes. It gets even worse
with more path elements. If someone makes a request for //foo//bar//baz.jsp,
the container should normalize it to /foo/bar/baz.jsp so that SecurityFilter
can match it to /foo/* (assuming such a url-pattern is present). But, Tomcat
doesn't seem to be doing the normalization correctly as of 4.1.18-LE-jdk14.
That is my current understanding.

-Max

>
> -Chris
>





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