Unfortunately, filters are skipped (ie. not called at all) when form-based
login page is processed as a result of client requesting a secure area.
We tried that too...
By the way, the original URL that the client requested is hidden in the
session in a way which prevents the web app from copying it to a new
session object.
Tomas
Darryl Miles
<darryl-mailingli
[EMAIL PROTECTED]> To
Tomcat Users List
10.08.2006 15:09 <[email protected]>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<[EMAIL PROTECTED]
che.org>
Well HTTP Cookies have a solution to this problem. They have a "Secure"
keyword in the Set-Cookie line. This stops the client leaking the
cookie outside of a secure channel.
The problem is I dont think Tomcat keeps track and flags if a session
has been exposed via a non-secure channel or not. If it did then thats
all a web-app filter needs to take action and invalidate the session
itself and pickup a new one (possibly transferring from old HttpSession
to new HttpSession any useful non-security related attributes in the
process).
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
