Introduction

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 sent a cookie with the correct content. So the browser must send the SecureSessionCookie now, after it was created.

Drawbacks for XHR requests

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.

To avoid such situations keep control over the XHR requests (with javascript code) to do the requests in a sequence (in case the secure session cookie is not set yet).

For performance reasons, there are two secure session cookies for:

• transient sessions (containing site and application server id in the hashed key) and
• persistent sessions (containing site in the hashed key)

Once the session switches the persistence (e.g. during login/logout) the cookie named switched.

The SMC is now using persistent sessions too.

Configuration for prefix of SecureSessionCookie (since 7.10.38.15)

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