You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Keith Wannamaker <Ke...@Wannamaker.org> on 2003/03/12 03:44:57 UTC
4.1 authentication bug / bug 14616
Greetings,
I brought this up in November. Remy and I have a disagreement
on how important fixing this bug is. I want to see if there is
a quorum of other committers who understand the problem and think
it should be fixed prior to the next stable build release of 4.1.
The immediate problem is that current Tomcat behavior causes
browsers to submit auth credentials to webapps other than the
webapp who originally sent the 401 challenge.
Most web servers, like Apache, are careful to redirect for
trailing slashes before challenging for authentication. Tomcat
does this backward. The result is the client will usually cache
the need for auth for the entire domain and not just a single
webapp.
Here is a repeat of the scenario I mentioned in November
<http://marc.theaimsgroup.com/?l=tomcat-dev&m=103673355109222&w=2>
<Context path="/foo" docBase="foo" />
<Context path="/bar" docBase="bar" />
foo and bar web.xml protected with
<security-constraint>
<web-resource-collection>
<web-resource-name>name </web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Current behavior:
Request Response
GET /foo 401
(at this point browsers will send credentials to any url in this domain)
GET /foo with auth 301 redirect to /foo/
GET /foo/ 200
GET /bar with auth
^^^^^^^^^
Correct behavior:
GET /foo 301 redirect to /foo/
GET /foo/ 401
GET /foo/ with auth 200
GET /bar without auth
^^^^^^^^^^^^
My proposed patch is attached to bug 14616
<http://issues.apache.org/bugzilla/show_bug.cgi?id=14616>
While this does not cover the case of subdirectories within
a context, it does fix the most egregious case for context
roots.
Please comment if you are not comfortable with credentials being
inadvertently shared between all webapps on a given domain.
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 4.1 authentication bug / bug 14616
Posted by Costin Manolache <cm...@yahoo.com>.
Bill Barker wrote:
>> I think it is reasonable to fix it.
>>
>> This can be serious - if someone relies on application isolation ( like
>> a hosting environment ), the consequences can be really bad, with
>> one webapp guessing the credentials of another one.
>> The fix seems reasonably simple and clean.
>>
>
> Except that it isn't really a fix. Like Remy, I'd like to see a more
> general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith
> wants to commit his patch. It does fix the worst-case condition.
Let's call it "a small improvement" :-)
Costin
>
>> Costin
>>
>> Keith Wannamaker wrote:
>>
>> > Greetings,
>> >
>> > I brought this up in November. Remy and I have a disagreement
>> > on how important fixing this bug is. I want to see if there is
>> > a quorum of other committers who understand the problem and think
>> > it should be fixed prior to the next stable build release of 4.1.
>> >
>> > The immediate problem is that current Tomcat behavior causes
>> > browsers to submit auth credentials to webapps other than the
>> > webapp who originally sent the 401 challenge.
>> >
>> > Most web servers, like Apache, are careful to redirect for
>> > trailing slashes before challenging for authentication. Tomcat
>> > does this backward. The result is the client will usually cache
>> > the need for auth for the entire domain and not just a single
>> > webapp.
>> >
>> > Here is a repeat of the scenario I mentioned in November
>> > <http://marc.theaimsgroup.com/?l=tomcat-dev&m=103673355109222&w=2>
>> >
>> > <Context path="/foo" docBase="foo" />
>> > <Context path="/bar" docBase="bar" />
>> >
>> > foo and bar web.xml protected with
>> > <security-constraint>
>> > <web-resource-collection>
>> > <web-resource-name>name </web-resource-name>
>> > <url-pattern>/*</url-pattern>
>> > </web-resource-collection>
>> > <auth-constraint>
>> > <role-name>admin</role-name>
>> > </auth-constraint>
>> > </security-constraint>
>> >
>> > Current behavior:
>> > Request Response
>> > GET /foo 401
>> > (at this point browsers will send credentials to any url in this
> domain)
>> > GET /foo with auth 301 redirect to /foo/
>> > GET /foo/ 200
>> > GET /bar with auth
>> > ^^^^^^^^^
>> >
>> > Correct behavior:
>> > GET /foo 301 redirect to /foo/
>> > GET /foo/ 401
>> > GET /foo/ with auth 200
>> > GET /bar without auth
>> > ^^^^^^^^^^^^
>> >
>> > My proposed patch is attached to bug 14616
>> > <http://issues.apache.org/bugzilla/show_bug.cgi?id=14616>
>> > While this does not cover the case of subdirectories within
>> > a context, it does fix the most egregious case for context
>> > roots.
>> >
>> > Please comment if you are not comfortable with credentials being
>> > inadvertently shared between all webapps on a given domain.
>> >
>> > Keith
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
RE: 4.1 authentication bug / bug 14616
Posted by Keith Wannamaker <Ke...@Wannamaker.org>.
Remy,
The fix corrects the bug, which is that credentials are shared
between webapps. As I've asked before, if there is a better way
to correct it, I'm all for it. There are a lot of bugs that have
been in the code for a long time, it doesn't mean they aren't bugs.
The behavior bothers me, and it would bother anyone else who
set up multiple webapps with authentication.
Keith
| -----Original Message-----
| From: Remy Maucherat [mailto:remm@apache.org]
| Sent: Wednesday, March 12, 2003 10:24 AM
| To: Tomcat Developers List
| Subject: Re: 4.1 authentication bug / bug 14616
|
|
| As I've said before, I don't really mind this bug, and the proposed
| solution is a hack. The behavior has been there forever, so apparently
| it doesn't bother anyone. So I prefer keeping the current behavior.
|
| The 5.0 mapper already handles that cleanly, and needs a little more
| code for directory redirect. I supposed along with the welcome file
| support change, that's a major behavior change.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 4.1 authentication bug / bug 14616
Posted by Remy Maucherat <re...@apache.org>.
Keith Wannamaker wrote:
> Hey Bill, thanks for the input. I am all ears if you can think of
> a better way to fix this in 4.1. Rather than forward-porting this
> fix to 5.0, I will look at better ways of doing it there since you
> indicate they exist.
>
> I think this is the way to go for 4.1 since it will fix both the
> most and the worst cases, namely inter-webapp credential sharing.
As I've said before, I don't really mind this bug, and the proposed
solution is a hack. The behavior has been there forever, so apparently
it doesn't bother anyone. So I prefer keeping the current behavior.
The 5.0 mapper already handles that cleanly, and needs a little more
code for directory redirect. I supposed along with the welcome file
support change, that's a major behavior change.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: 4.1 authentication bug / bug 14616
Posted by Keith Wannamaker <Ke...@Wannamaker.org>.
Hey Bill, thanks for the input. I am all ears if you can think of
a better way to fix this in 4.1. Rather than forward-porting this
fix to 5.0, I will look at better ways of doing it there since you
indicate they exist.
I think this is the way to go for 4.1 since it will fix both the
most and the worst cases, namely inter-webapp credential sharing.
Keith
| -----Original Message-----
| From: Bill Barker [mailto:wbarker@wilshire.com]
| Sent: Wednesday, March 12, 2003 1:28 AM
| To: Tomcat Developers List
| Subject: Re: 4.1 authentication bug / bug 14616
|
|
|
| ----- Original Message -----
| From: "Costin Manolache" <cm...@yahoo.com>
| To: <to...@jakarta.apache.org>
| Sent: Tuesday, March 11, 2003 8:52 PM
| Subject: Re: 4.1 authentication bug / bug 14616
|
|
| > I think it is reasonable to fix it.
| >
| > This can be serious - if someone relies on application isolation ( like
| > a hosting environment ), the consequences can be really bad, with
| > one webapp guessing the credentials of another one.
| > The fix seems reasonably simple and clean.
| >
|
| Except that it isn't really a fix. Like Remy, I'd like to see a more
| general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith
| wants to commit his patch. It does fix the worst-case condition.
|
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 4.1 authentication bug / bug 14616
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, March 11, 2003 8:52 PM
Subject: Re: 4.1 authentication bug / bug 14616
> I think it is reasonable to fix it.
>
> This can be serious - if someone relies on application isolation ( like
> a hosting environment ), the consequences can be really bad, with
> one webapp guessing the credentials of another one.
> The fix seems reasonably simple and clean.
>
Except that it isn't really a fix. Like Remy, I'd like to see a more
general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith
wants to commit his patch. It does fix the worst-case condition.
> Costin
>
> Keith Wannamaker wrote:
>
> > Greetings,
> >
> > I brought this up in November. Remy and I have a disagreement
> > on how important fixing this bug is. I want to see if there is
> > a quorum of other committers who understand the problem and think
> > it should be fixed prior to the next stable build release of 4.1.
> >
> > The immediate problem is that current Tomcat behavior causes
> > browsers to submit auth credentials to webapps other than the
> > webapp who originally sent the 401 challenge.
> >
> > Most web servers, like Apache, are careful to redirect for
> > trailing slashes before challenging for authentication. Tomcat
> > does this backward. The result is the client will usually cache
> > the need for auth for the entire domain and not just a single
> > webapp.
> >
> > Here is a repeat of the scenario I mentioned in November
> > <http://marc.theaimsgroup.com/?l=tomcat-dev&m=103673355109222&w=2>
> >
> > <Context path="/foo" docBase="foo" />
> > <Context path="/bar" docBase="bar" />
> >
> > foo and bar web.xml protected with
> > <security-constraint>
> > <web-resource-collection>
> > <web-resource-name>name </web-resource-name>
> > <url-pattern>/*</url-pattern>
> > </web-resource-collection>
> > <auth-constraint>
> > <role-name>admin</role-name>
> > </auth-constraint>
> > </security-constraint>
> >
> > Current behavior:
> > Request Response
> > GET /foo 401
> > (at this point browsers will send credentials to any url in this
domain)
> > GET /foo with auth 301 redirect to /foo/
> > GET /foo/ 200
> > GET /bar with auth
> > ^^^^^^^^^
> >
> > Correct behavior:
> > GET /foo 301 redirect to /foo/
> > GET /foo/ 401
> > GET /foo/ with auth 200
> > GET /bar without auth
> > ^^^^^^^^^^^^
> >
> > My proposed patch is attached to bug 14616
> > <http://issues.apache.org/bugzilla/show_bug.cgi?id=14616>
> > While this does not cover the case of subdirectories within
> > a context, it does fix the most egregious case for context
> > roots.
> >
> > Please comment if you are not comfortable with credentials being
> > inadvertently shared between all webapps on a given domain.
> >
> > Keith
>
>
>
> ---------------------------------------------------------------------
> 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
Re: 4.1 authentication bug / bug 14616
Posted by Costin Manolache <cm...@yahoo.com>.
I think it is reasonable to fix it.
This can be serious - if someone relies on application isolation ( like
a hosting environment ), the consequences can be really bad, with
one webapp guessing the credentials of another one.
The fix seems reasonably simple and clean.
Costin
Keith Wannamaker wrote:
> Greetings,
>
> I brought this up in November. Remy and I have a disagreement
> on how important fixing this bug is. I want to see if there is
> a quorum of other committers who understand the problem and think
> it should be fixed prior to the next stable build release of 4.1.
>
> The immediate problem is that current Tomcat behavior causes
> browsers to submit auth credentials to webapps other than the
> webapp who originally sent the 401 challenge.
>
> Most web servers, like Apache, are careful to redirect for
> trailing slashes before challenging for authentication. Tomcat
> does this backward. The result is the client will usually cache
> the need for auth for the entire domain and not just a single
> webapp.
>
> Here is a repeat of the scenario I mentioned in November
> <http://marc.theaimsgroup.com/?l=tomcat-dev&m=103673355109222&w=2>
>
> <Context path="/foo" docBase="foo" />
> <Context path="/bar" docBase="bar" />
>
> foo and bar web.xml protected with
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>name </web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>admin</role-name>
> </auth-constraint>
> </security-constraint>
>
> Current behavior:
> Request Response
> GET /foo 401
> (at this point browsers will send credentials to any url in this domain)
> GET /foo with auth 301 redirect to /foo/
> GET /foo/ 200
> GET /bar with auth
> ^^^^^^^^^
>
> Correct behavior:
> GET /foo 301 redirect to /foo/
> GET /foo/ 401
> GET /foo/ with auth 200
> GET /bar without auth
> ^^^^^^^^^^^^
>
> My proposed patch is attached to bug 14616
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=14616>
> While this does not cover the case of subdirectories within
> a context, it does fix the most egregious case for context
> roots.
>
> Please comment if you are not comfortable with credentials being
> inadvertently shared between all webapps on a given domain.
>
> Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org