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]