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=6279>. 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=6279 Resubmit to j_security_check mistakenly fetches a page of that name [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Medium |Low ------- Additional Comments From [EMAIL PROTECTED] 2002-06-06 09:37 ------- I was the original submitter. Some of what I said was misplaced. Even if the code was changed as I describe to allow users to log in again, it wouldnt work. This is because the request is still for j_security_check. The request would now fail with an SC_BAD_REQUEST - exactly as you would get if you bookmarked the login page. That issue - that the user has actually managed to log in, but we dont know what page to take them to - can not be solved portably across servlet engines under the spec. Currently I get round it on tomcat by trapping the 400 error and taking the user to an appropriate page, because there are few other places where 400 errors are thrown (in the Certificate auth and WebDav code). When JSR 154 (servlet 2.4) goes to public review (later this month, hopefully) I'm going to request that a specific exception is thrown in this case, to provide a portable way to trap the error. ****WARNING**** A further issue with the fix I posted is that the user changes within the same session. This is a SECURITY HOLE. Details from one user may leak to a second user through reuse of the session. The session must be closed and a new session opened if the user logs in with new credentials. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
