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) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-09 18:19 --- Having found the time to have a look at swapping the order of the redirects (for FORM only) as suggested by Bill Barker on the TomcatDev list, there is an unexpected side-effect that I wasn't expecting. The first re-direct is to http://server:8080/myapp/protected/Login.html as expected. However, the second re-direct that you would expect to use https doesn't occur. The reason is that the user data constraint is picked up from the login user data constraint and not the app user data constraint. If the app is configured for ssl but the login is not, then the login will be in the clear. The current code, where the redirect for user data constraint occurs first ensures that the apps user data constraint is applied to the login as well, even if the login does not have one. Given the above plus - the bug is really an IE bug, not a tomcat one - there is a work around available - the bug only appears when using non-standard ports I am now of the opinion that this should be a WONTFIX. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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) [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.18 |4.1.24 --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 22:51 --- I have looked into this and this is still present in 4.1.24. I'll update the version associated with this bug accordingly. It is not present in 5.x.x. This is because 5.x.x uses forward rather than redirect for form logins. (see bug 21666) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13861] - Authentication / SSL conflict (web.xml security-constraint auth-constraint user-data-constraint)
- Original Message - From: Mark Thomas [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 2002-12-28 16:55 --- Created an attachment (id=4278) workaround: web.xml -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] 2002-12-28 16:55 --- Created an attachment (id=4279) workaround: loginforward.jsp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] 2002-12-28 17:08 --- Created a workaround for this bug. Finally I found out how to avoid that IE is forced to redirect to https AND a login at the same time. You can implement a two-phase login that works with IE and Tomcat on ports 8080/8443. 1. Your login link should load the loginforward.jsp (in any case you should avoid to link to your login.jsp directly because of several other issues with j_security) This loginforward.jsp resource is protected with a security constraint confidential, but NO login/role (check web.xml). Thus IE will successfully load this page via https. The http-to-https redirect mechanism works for this case. 2. loginforward.jsp will now force the client browser to do a refresh. The page to come up after refresh is either the login form page or (if already logged in) the index.jsp of the protected directory. This will now also work for IE because IE already changed to https protocol beforehand. Maybe somebody can confirm this workaround. Certainly not a perfect solution for this annoying problem, but works for me. From the usability point of view it's nearly transparent for the user as he won't see much of the loginforward.jsp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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) [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.12 |4.1.18 --- Additional Comments From [EMAIL PROTECTED] 2002-12-26 23:09 --- Updated to Tomcat 4.1.18 today. Thus I'll change the version from 4.1.12 to 4.1.18 now. The problem is still present. Internet Explorer 6.0 won't automatically redirect from http to https when using ports 8080/8443 instead of 80/443. I wonder if this is a Tomcat or an IE bug because all other browsers that I tried work as expected even with 8080/8443. Only workaround: use port 80/443 with Tomcat or place Apache on ports 80/433 in front of Tomcat using a jk-Connector (not forget to set redirect attribute to 443, too.) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] 2002-11-22 16:27 --- I'm experiencing the same thing, but when it times out, I get the url with a jsessionid attached to it. Also it changes http to https, but not the port number. Now if I keep the jsessionid and the rest of the url, and switch it back to http://localhost:8080, it will then magically redirect to https://localhost:8443 See my comments in this post to the tomcat-users list for more details... http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg74611.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] 2002-11-16 14:05 --- I can confirm this bug. Actually the problem is only transport-guaranteeCONFIDENTIAL/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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
