If your first hit to the jboss application happens to be https, the server will issue a "Secure" JSESSIONID cookie. As soon as you get off https, your server then issues a new non-secure JSESSIONID cookie and so you loose your session.
FIrst hit to site:
<- issues secure JSESSIONID cookie
Second hit to site:
<- issues new non-secure JSESSIONID cookie, so the fact that you logged in is lost.
First hit to site:
<- issues non-secure JSESSIONID cookie
Second hit to site:
<- previous non-secure JSESSIONID cookie is used, all is well.
Wondering what ways people have found to get around this issue. I had an unsupported valve provided by ATG support for jboss4.0.3, but now that we are upgradeing to jboss5.1.0, we find the valve doesn't work.
It a default Jboss behavior o secure JSESSIOn cookie for HTTPS request but I think you can configure Jboss not to secure JSESSION cookie for HTTPS requests.
Thought its not always recommended because of security vulnerability. I malicious user can steel your cookie from HTTP request.
The other recommended way is to implement HTTPS throughout your website. Obviously it also comes with a cost in tearms of SSL overhead, cost over head, and if you are using cross domain session cookie where one domain is secure other not.
It is certainly JBOSS default behavior to issue a secure cookie when the first request to the site is done over https. There is no way to configure jboss to not use the secure cookie as far as I know - something custom is required here.
For a site that uses a mix of http and https, this behavior makes no sense to me. The secure cookie is only issued if your first hit happens to be over https, which is rare. Most of the time, your first hit will be http, in which case a non-secure cookie is issued and used for the remainder of the session.
Did you try setting
<SessionCookie path="/" secure="false" httpOnly="false"/>
in J2EE application context.xml?
Also "everything on HTTPS" is the the recommended approach by security experts. Having both HTTP and HTTPS on your site open vulnerability towards MITM attack.