We have the following situation going on:
Go to http://website/ and click on a link to http://website/appX
Check that the cookie shows JSessionID with secure = NO.
Open another browser window or tab and go to https://website/ and click on a link to https://website/appY.
Check that the cookie shows JSessionID with secure = YES.
Try to interact with the window/tab created in step 1. I'm getting a session expired...
If we repeat the steps but use https://website/appX instead of https://website/appY in step2, then the JSessionID cookie remains with Secure=NO.
All cookies have JSessionId with jvmRoute appended in the end.
--
We are using:
Apache (2.2.3-43.el5_5.3) + mod_jk (w/ sticky sessions) and load balancer configured to several JBoss instances (v 4.3.0).
I have found only a link with the exact same issue (normally the other ones are using PHP):
http://threebit.net/mail-archive/tomcat-users/msg17687.html
Q: How can we prevent the JSessionId cookie from being rewritten ?
From a security point of view, it is the correct behavior, because a attacker could steal the session id/cooki used in https if the same session id/cooki is used in http too.
For more details see my answer here.
So if you want to build a secure application (I excpect this, because you use https), then you must not change this!
SessionID/Cookie will not be preserved when making switch from HTTPS to HTTP or vice versa. You can pass these parameters in URL to pass the values.
In the connector configuration (for Tomcat's bundled version in JBoss) in deploy/jboss-web.deployer/server.xml, there's an emptySessionPath
attribute that controls whether the session cookie is set on the context path or not.
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
If you set this to false, you'll have one cookie per application, which prevents the problem from happening.