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]>
