[Tomcat-users] Session Invalidate not working on HTTPS ( Tomcat 6.0.29 )

Andrea,
As you may have noted, Tomcat has implemented this behavior and you
shouldn't have to worry about it.
Okay, what does the above servlet print when you access it via HTTP, and
then access it via HTTPS?

- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

2010/11/29 Christopher Schultz <chris@christopherschultz.net>
HTTP Output:
POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC New=true
pre- invalidate
sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
by a HttpSessionListener
post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
a HttpSessionListener
post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

We can notice that the session id after the GetSession(true) is different
from the previous one.

HTTPS Output:
POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A New=false
pre- invalidate
sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
by a HttpSessionListener
post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
a HttpSessionListener
post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

In this case the session id is always the same!

Can someone suggest a way to avoid such issue? I saw that between release 28
and 29 the following class has been changed but i'm not able to debug it.
java\org\apache\catalina\connector\Response.java (method
addSessionCookieInternal)

Thanks.

Andrea

http://wiki.apache.org/tomcat/FAQ/Developing

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Yes, I have emptySessionPath=true in connectors; is this the issue?

Thanks for the link, now i'm trying to debug in order to find some more
details for you experts.

Thanks.

2010/11/30 Konstantin Kolinko <knst.kolinko@gmail.com>

In your logs, you have "sessionCreated" message, i.e. a session was
created and thus the listener was notified, but the ID was reused.

You can put a breakpoint in your listener to see where that comes from.

-> "manager.createSession(getRequestedSessionId());" call in
o.a.c.connector.Request.doGetSession(..)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Hi, i discovered that (perhaps) the problem raise in the following rows in
the Request class:

// Attempt to reuse session id if one was submitted in a cookie
// Do not reuse the session id if it is from a URL, to prevent
possible
// phishing attacks
if (connector.getEmptySessionPath()
&& isRequestedSessionIdFromCookie()) {
session = manager.createSession(getRequestedSessionId());
} else {
session = manager.createSession(null);
}

I have an empty sessionpath =true and the sessionid is stored in the
jsessionid cookie so the code goes in the first if reusing the sessionid.
I don't understand very well the comment in the code where it says "Attempt
to reuse session id if one was submitted in a cookie"; is there any reason
for this?
Is it correct to comment this if statement in order to always call the
createSession(null) or is there another way in order to workaround this?

Thanks in advance.

Andrea



2010/11/30 Andrea Corti <ilgrandemazinger@gmail.com>

That will mean that every web application will use its unique value of
sessionid. Thus you can never share sessionid between them.

Effectively, that is not far away from just setting emptySessionPath="false".

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Common_Attributes

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Konstantin,
So it's a feature, not a bug :)

Andrea, if the webapp changes the session id, it may break other
applications that were relying on the session id /not/ to change. This
only happens when "emptySessionPath" is set to true, which is usually
only done when sessions are being shared across webapps.

Konstantin, can you confirm that behavior is different if you are using
single sign-on?

- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

The single sign on is a separate cookie with its own life. The
sessions live independently and have their own IDs.

See o.a.c.authenticator.SingleSignOn

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org