You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/11/16 15:05:10 UTC

DO NOT REPLY [Bug 13861] - Authentication / SSL conflict (web.xml security-constraint auth-constraint user-data-constraint)

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 mech@rz.fh-augsburg.de  2002-11-16 14:05 -------
I can confirm this bug. 

Actually the problem is only
<transport-guarantee>CONFIDENTIAL</transport-guarantee> (or INTEGRAL).

in connection with the MS Internet Explorer 6.x!

Usually I expected a redirect to https on port 8443 whenever I try to access a
secured http url. Of course, you need SSL running.

The interesting thing is that this behaviour works fine when I use Mozilla or
Opera browser. 
I enter a http url into my Internet Explorer however, I only get the ssl warning
popup (because using a self-signed test certificate, of course. so far so good.
that is normal) and after that IE stops loading! 
The status bar is moving slowly but it stalls doing nothing anymore. But it
works fine if i access the page directly with https. So actually the redirection
i not working when using IE.

One more thing I found out after studying some related messages in the
tomcat-user list, was that it's obviously working with IE when http/https are
running on standard ports 80/443, although i haven't tried myself.

More related info here:
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg73342.html

http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg59950.html

(There seem to be many related mails like this, but most users obviously think,
it's a self-made SSL configuration issue instead of a bug!)

Maybe the url rewriting with IE just changes the protocol from http to https
when sending the new request leaving the port unchanged which can only work with
standard ports.

Hope some solution can be found for this soon. Otherwise container managed
security is nearly useless. I don't want to hardcode absolute "https" urls in my
code and all links to make sure that any IE client is not hanging.

At least it should be noted that this is a bug otherwise more users try to
figure out what is wrong with their SSL and container managed security setups.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>