This version contains a reworked SecureSessionCookie (or Token) behavior.
The SecureSession token will be stored at login, logout and pipelines, which are marked as session persistent. So the fail over to other application server will work correctly now. Transient session will retrieve a new secure session token (e.g. during anonymous user browsing).
For security reasons, we removed the internal acceptance state of the token. This was set, if the browser has send a cookie with the correct content. So the browser must send the SecureSessionCookie now, after it was created.
Some early adapters faced the problem, that in some cases two XHR requests are triggered by the browser at the same time. In the case, both requests are not cached and are forwarded to the application server (AS), the AS can't decide, if one or the other or both requests came from the same client. This leads to "session hijacked" errors, if the AS stores the token in one of the requests and the other is checked afterwards.
For performance reasons, there are two secure session cookies for:
Once the session switches the persistence (e.g. during login/logout) the cookie named switched.
The SMC is now using persistent sessions too.
Also for security reasons, we changed the default name of the cookie to "__Host-SecureSessionID-". The configuration key "
intershop.session.securetoken.cookie.name" can overrule this prefix. For more information see https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.