RE: 4.1 authentication bug / bug 14616
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:[EMAIL PROTECTED] | 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 [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 4.1 authentication bug / bug 14616
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 4.1 authentication bug / bug 14616
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:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. 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-devm=103673355109222w=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-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (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 /foo301 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 4.1 authentication bug / bug 14616
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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-devm=103673355109222w=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-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (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 /foo301 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 4.1 authentication bug / bug 14616
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-devm=103673355109222w=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-namename /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint Current behavior: Request Response GET /foo401 (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 /foo301 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
