tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
Date Thu, 06 Jun 2002 09:37:48 GMT
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

Brian.Ewins@btinternet.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Medium                      |Low



------- Additional Comments From Brian.Ewins@btinternet.com  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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message