Introduction
A session represents the period of time during which a user actively uses a site.
A session is referenced to store the authentication state across multiple requests. The authentication state can change during a session, allowing the user to log in and log out within the same session. The user can use different sites within the same session. Each site has its own authentication state and a separate session instance on the server.
A session can store session-related information, such as:
Products visited during the session
Affiliate information
A/B test assignments
Login State
A session can have three login states, which represent the authentication state:
State | Description |
|---|---|
volatile/unknown/new | An artificial state for newly created sessions. See the section "Session Fail-Over." In this state, the server does not know if the user is logged in or not. |
anonymous | The user has not logged in yet. For example, an anonymous user can have a basket or may have entered personal data for registration or checkout. |
logged-in | The user is authenticated. |
The session cookie does not contain any authentication information. The authentication state is secured via the secure session token.
Persistence Of Sessions
A session can be stored in the database. This is necessary to support different kinds of session fail-over scenarios.
State | Description |
|---|---|
volatile | An artificial state for newly created sessions. See the section Session Fail-Over. In this state, the server does not know if the session is stored in the database or not. |
transient | The session is not stored in the database. |
persistent | The session is stored in the database. |
Session Fail-Over
A session fail-over is a re-trigger of loading the session from persistence. A reload occurs if:
The session is not available in the session table (session cache on the application server)
The secure session token does not match the secure session cookie
Scenario | Description |
|---|---|
Server Shutdown | The application server instance is no longer available to serve requests. The Web Adapter (WA) will choose another application server. This server does not have a “session-table” entry for this session. |
Session Timeout | The session has timed out or expired. The "session table" is periodically cleaned to remove such sessions. |
Session Table Overflow | To protect the server instance and avoid memory leaks that lead to unexpectedly long response times, the "session table" can only hold a specific number of sessions. These sessions are semi-parallel, the user could leave the site without telling. These inactive sessions are indented to be removed, in case the “session table” reaches the maximum amount of stored sessions. In case of a session table overflow, “non-expired” sessions could be cleaned from “session-table”. |
All scenarios result in the user providing an "unknown" session-id.
Session Table
Sessions are stored locally in the SessionTable, which is a cache that stores sessions by sessionID and domainID. To prevent resource leaks, this cache is limited by size (number of cached sessions), and the lifetime of its entries is restricted by the global session timeout. Both values can be configured.:
The following table applies to ICM version 7.10.x.x
Applicable ICM version(s) | Semantics | Property key | Default value | Max value |
|---|---|---|---|---|
>= 7.10 |
|
| 30 minutes | 35700 minutes |
>= 7.10.40.4, < 11.x | Number of session cached |
| 10000 | 231-1 |
>= 11.x, < 12.x | Number of session cached | Sub value
| 2000 | 231-1 |
>= 12.x | Number of session cached | Sub value
| 2000 | 231-1 |
For information on Guava/Caffeine cache configuration, refer to Guide - Cache Engine Administration.
Secure Session Token
The secure session token is a random string stored in the server's session instance (one per site) and provided to the browser (or other client) via a cookie. Only if the provided session-id and the secure session token match, the stored authentication state is resolved or accepted.
Different secure session token cookies are used for transient and persistent sessions because transient sessions are only valid on a single application server instance.
Different secure session token cookies are used for different sites to allow distinct authentication states for each site.
Standard (Simple) Flow
The standard flow applies to all pages that are not found in the cache and do not contain any remote includes in the response.
There are more complex scenarios in the following cases:
Usage of remote includes:
A remote include request cannot contain the session cookie if the session token was created in the top-level request or during an earlier remote include.Usage of snippet loading via JavaScript:
Two requests can be triggered in parallel
Local Login via Username/E-mail
A channel preference (key UserRegistrationLoginType) “Login Type” has two options:
E-mail or
Username (also known as “login”)
Info
The preference does not define which field is used for login. It is always the "login" field.
The preference specifies that if a user changes their e-mail address, the "login" field is also updated.
The preference adapts some pages in Customer and Business User Management in the channel back office.
Login, registration and profile settings in PWA or Responsive Storefront are adapted as well.
Intershop strongly recommends to avoid switching between the two login types after the store is live.
Different Visuals for These Two Options
The following screenshots show how the two settings affect the back office and the storefront.
Username/Login
Impact of Switching Login Preferences
The database content is not changed during a switch; only the "flag" itself is updated. This means that existing usernames/logins and e-mail addresses remain unchanged.
This can result in a scenario where the username and e-mail address differ, and the preference is set to use E-mail. In such cases, the user cannot log in and must use the reset password functionality. It is not possible to use the e-mail address as login, because the e-mail address must not be unique. Allowing e-mail usage could enable users to take over other accounts or create multiple accounts with the same e-mail address.
To prevent this situation, the shop provider can notify users about the switch in advance. This allows users to update their "login/username" to match their preferred e-mail address.
Switch from Username to E-mail
When Username is selected as the login preference, the username and e-mail are updated individually across the back office, storefront, and import processes.
Steps:
Change the preference: No changes are made to the database for users, profiles, or credentials.
The customer view in the back office now provides E-mail/Login as a single input field.
The storefront login page displays E-mail instead of Username.
Try to login in to the storefront: This will fail in case the username is different than the e-mail.
With username: Login fails because the username is not an e-mail, and the login page validates the input as an e-mail before sending the request.
With e-mail: Login fails because the provided e-mail does not match the stored
loginvalue in the database.
User needs to use the Forgot your password? link. However, it will not work.
The Forgot your password? link does not work because the system cannot identify the user based on the provided e-mail address. The database still contains the "old" username as the login name.
Switch From E-mail to Username
When E-mail is selected as the login preference, the username and e-mail are updated individually during the import processes. Additionally, the username is automatically updated whenever the e-mail is changed in the back office or storefront actions and views.
Steps:
Change the preference: No changes are made to the database for users, profiles, or credentials.
The customer view in the back office now provides separate input fields for E-mail and Login.
The storefront login page now displays Username instead of E-mail.
Try to login in to the storefront: This should be successful.
The user still uses their e-mail address as the Username because the Username is equal to the E-mail.