You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <me...@ntlworld.com> on 2003/07/18 01:09:32 UTC
RE: DO NOT REPLY [Bug 13861] - Authentication / SSL conflict (web.xml security-constraint auth-constraint user-data-constraint)
All,
I would like to write a patch for this bug but before I do I have a few
questions
I would value your opinions on:
1. If the root cause is an IE but, should we do anything?
2. If we do make a change, is it reasonable to modify
org.apache.coyote.http11.Http11Processor.parseHost()
to always use the port from the associated socket. I am afraid I do not know
enough
about the specs to answer this one.
3. Is there a better fix?
My own view is that we should do something to help our users even if it isn't
strictly
our fault. Trying to get Microsoft to fix it is a waste of time in my view.
I've tried
that route before with no success.
Thanks in anticipation for your responses,
Mark
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13861>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13861
Authentication / SSL conflict (web.xml security-constraint auth-constraint
user-data-constraint)
------- Additional Comments From medthomas@ntlworld.com 2003-07-17 23:04
-------
As far as I can tell this is an IE bug. Using the snoop example, Tomcat first
redirects to SSL and then performs a second redirect to the form login jsp.
The response sent by IE to the first redirect comes in on port 8443 but the
request headers refer to port 8080 (read in
org.apache.coyote.http11.Http11Processor.parseHost()). This causes the second
redirect to fail because the port in the request is used when constructing the
second redirect.
You will not see this problem if the standard ports are used because Tomcat
defaults to these if the port is not specified in the headers.
Work arounds are as suggested in the previous posts
1. Use the standard ports
2. Use a two stage re-direct
I'll start a discussion on the developers list to gather opinions as to what,
if anything, we should do about what looks very much like an IE bug.
---------------------------------------------------------------------
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: DO NOT REPLY [Bug 13861] - Authentication / SSL conflict (web.xml security-constraint auth-constraint user-data-constraint)
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Mark Thomas" <me...@ntlworld.com>
To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
Sent: Thursday, July 17, 2003 4:09 PM
Subject: RE: DO NOT REPLY [Bug 13861] - Authentication / SSL conflict
(web.xml security-constraint auth-constraint user-data-constraint)
> All,
>
> I would like to write a patch for this bug but before I do I have a few
> questions
> I would value your opinions on:
>
> 1. If the root cause is an IE but, should we do anything?
I don't have a strong opinion either way on this.
> 2. If we do make a change, is it reasonable to modify
> org.apache.coyote.http11.Http11Processor.parseHost()
> to always use the port from the associated socket. I am afraid I do not
know
> enough
> about the specs to answer this one.
This one is really bad. It breaks way more things than it fixes (e.g.
hardware load-balancers, proxy-servers).
> 3. Is there a better fix?
Looking at the discussion on #13861, it seems at it is enough to simply
(for the special case of FORM only, since it is clearly wrong to do this for
BASIC), reverse the order of the checks for user-data and auth-constraint.
Then a request for http://server:8080/myapp/protected/ would first go to
http://server:8080/myapp/protected/Login.html and then to
https://server:8443/myapp/protected/Login.html. As I understand it this
should work with MSIE (but I haven't tried it myself). It's easy enough to
do a quick hack to test it: Just swap the calls to checkUserData and
authenticate in AuthenticatorBase.
>
> My own view is that we should do something to help our users even if it
isn't
> strictly
> our fault. Trying to get Microsoft to fix it is a waste of time in my
view.
> I've tried
> that route before with no success.
>
> Thanks in anticipation for your responses,
>
> Mark
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13861>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13861
>
> Authentication / SSL conflict (web.xml security-constraint auth-constraint
> user-data-constraint)
>
>
>
>
>
> ------- Additional Comments From medthomas@ntlworld.com 2003-07-17 23:04
> -------
> As far as I can tell this is an IE bug. Using the snoop example, Tomcat
first
> redirects to SSL and then performs a second redirect to the form login
jsp.
> The response sent by IE to the first redirect comes in on port 8443 but
the
> request headers refer to port 8080 (read in
> org.apache.coyote.http11.Http11Processor.parseHost()). This causes the
second
> redirect to fail because the port in the request is used when constructing
the
> second redirect.
>
> You will not see this problem if the standard ports are used because
Tomcat
> defaults to these if the port is not specified in the headers.
>
> Work arounds are as suggested in the previous posts
> 1. Use the standard ports
> 2. Use a two stage re-direct
>
> I'll start a discussion on the developers list to gather opinions as to
what,
> if anything, we should do about what looks very much like an IE bug.
>
> ---------------------------------------------------------------------
> 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
>