tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Date Fri, 12 Dec 2003 07:41:17 GMT
N.B. The Filter mapping code looks broken to me.  It looks like if I have a
mapping for a url-pattern '*.jsp' that has <dispatcher>INCLUDE</dispatcher>,
then it will incorrectly match a <jsp:include page="header.jspf" />.

However, I haven't actually tested it. :).

"Bill Barker" <wbarker@wilshire.com> wrote in message
news:009e01c3c01d$13f2a700$ec66a8c0@bbarkerxp...
>
> ----- Original Message -----
> From: "Remy Maucherat" <remm@apache.org>
> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
> Sent: Thursday, December 11, 2003 1:40 AM
> Subject: Re: cvs commit:
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
> RealmBase.java
>
>
> > billbarker@apache.org wrote:
> > > billbarker    2003/12/10 21:50:39
> > >
> > > Modified:    catalina/src/share/org/apache/catalina Realm.java
> > > catalina/src/share/org/apache/catalina/authenticator
> > > AuthenticatorBase.java catalina/src/share/org/apache/catalina/realm
> > > RealmBase.java Log: First attempt to get Tomcat compliant with the
> > > Servlet 2.4 Spec for AA.
> > >
> > > This one isn't very efficient (but not much worse than it was before
> > > :).  Longer term, I'm looking to modify the j-t-c mapper to be able
> > > to return a Collection of mapped objects, and use that.  In that case
> > > it could also be used for Filter mappings.
> >
> > Filter mapping is simple, and should be efficient enough right now. It
> > was really horrible in 4.1.x (except if somehow all filters are mapped
> > to /* or the exact path :-D), and is obviously used a lot more in 5.0.x,
> > so I did fix it. I was planning to use something fancy when I noticed
> > the requirements for this algorithm:
> > - we have try all the mappings in order, which voids any possible
> > optimization
> > - I think we only have a String at our disposal for filter mapping:
> > getting a char array would remove any performance benefit
> > - we don't have to generate any paths or similar stuff from the mapping
> > results
> > - there was this regionMatches method in String that could do that
> > matching test efficiently
> > And the profiler seems happy :) Maybe it's lying though.
> >
> > For the contraint mapping, since we also have to test them all and
> > return yes/no for each, I recommend using a similar custom algorithm.
> >
>
> I see your point on char array.  I'll probably leave it as Strings.  I'll
> also look at the Filter mapping code.
>
>   However, the entire point of the exercise is that we *don't* have to
test
> all of the security-constraints.  If I have a security-constriaint with a
> <url-pattern>/protected/*</url-pattern>, and another one with
> <url-pattern>*.jsp</url-pattern>, then for a request to
> /myapp/protected/index.jsp, only the first constraint is checked.  If you
> don't believe me, read 12.8.3 ;-).
>
> > > This version is just to get a Spec compliant version out there that
> > > can be tested.
> >
> > Rémy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>


----------------------------------------------------------------------------
----


>
> This message is intended only for the use of the person(s) listed above as
the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
>
>


----------------------------------------------------------------------------
----


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message