Secure >
Session management
Web browsers and e-commerce sites use HTTP to communicate. Since HTTP is a stateless protocol (meaning that each command is executed independently without any knowledge of the commands that came before it), there must be a way to manage sessions between the browser side and the server side.
WebSphere Commerce supports two types of session management: cookie-based and URL rewriting.
- Cookie-based session management
When cookie-based session management is used, a message (cookie) containing user's information is sent to the browser by the Web server. This cookie is sent back to the server when the user tries to access certain pages. By sending back the cookie, the server is able to identify the user and retrieves the user's session from the session database; thus, maintaining the user's session. A cookie-based session ends when the user logs off or closes the browser. Cookie-based session management is secure and has performance benefits. Cookie-based session management is secure because it uses an identification tag that only flows over SSL. Cookie-based session management offers significant performance benefits because the WebSphere Commerce caching mechanism only supports cookie-based sessions, and not URL rewriting. Cookie-based session management is recommended for customer sessions.
If you are not using URL rewriting and to ensure that users have cookies enabled on their browsers, check Cookie acceptance test on the Session Management page of Configuration Manager. This informs the customer that if their browser does not support cookies, or if they have turned off cookies, they need a browser that supports cookies to browse the WebSphere Commerce site.
For security reasons, cookie-based session management uses two types of cookies:
- Non-secure session cookie
Used to manage session data. Contains an activity identifier that points to attributes such as the negotiated language, current store, and customer's preferred currency at the time the cookie is constructed. This cookie can flow between the browser and server under either SSL or non-SSL connection. There are two types of non-secure session cookies:
- A WebSphere Application Server session cookie is based on the servlet HTTP session standard. WebSphere Application Server cookies persist to memory or to the database in a multinode deployment. For more information, see the Session management support topic in the WebSphere Application Server Information Center.
- A WebSphere Commerce session cookie is internal to WebSphere Commerce and does not persist to the database.
To select which type of cookie to use, select WCS or WAS for the Cookie session manager parameter on the Session Management page of Configuration Manager.
- Secure authentication cookie
Used to manage authentication data. An authentication cookie flows over SSL and is time-stamped for maximum security. This is the cookie used to authenticate the user whenever a sensitive command is executed, for example, the DoPaymentCmd, which asks for a user's credit card number. There is minimal risk that this cookie could be stolen and used by an unauthorized user. Authentication code cookies are always generated by WebSphere Commerce whenever cookie-based session management is in use.
Both the session and authentication code cookies are required to view secure pages.
For cookie errors, the CookieErrorView is called under the following circumstances:
- The user has logged in from another location with the same Logon ID.
- The cookie became corrupted, or was tampered with or both.
- If cookie acceptance is set to "true" and the user's browser does not support cookies.
- URL rewriting
With URL rewriting, all links that are returned to the browser or that get redirected have the session ID appended to them. When the user clicks these links, the rewritten form of the URL is sent to the server as part of the client's request. The servlet engine recognizes the session ID in the URL and saves it for obtaining the proper object for this user.
To use URL rewriting, HTML files (files with .html or .htm extensions) cannot be used for links.
To use URL rewriting, JSP pages must be used for display purposes. A session with URL rewriting expires when the customer logs off.
Notes:
- Because URLs returned to the browser contain session IDs, another user with access to the browser history (for example, on a shared computer) could potentially gain access to sensitive information exchanged during a session - if the session has been left active.
To prevent such unauthorized access, site developers should consider adding a notice to their site urging customers to always log off at the end of their visit, thereby ending (expiring) their session, particularly on a shared computer.
- WebSphere Commerce dynamic caching and URL rewriting cannot interoperate. With URL rewriting turned on, disable WebSphere Commerce dynamic caching.
The administrator can choose to support either only cookie-based session management or both cookie-based and URL rewriting session management. If WebSphere Commerce only supports cookie-based, customers' browsers must be able to accept cookies. If both cookie-based and URL rewriting are selected, WebSphere Commerce first attempts to use cookies to manage sessions; if the customer's browser is set to not accept cookies then URL rewriting is used.
Session cookies
WebSphere Commerce contains the following session cookies:
WebSphere Commerce session cookies
Cookie name Description WC_SESSION_ESTABLISHED This cookie is created on the first request processed by WebSphere Commerce runtime. For example, a non-cache request. See Dynamic caching considerations for persistent session for more information. WC_ACTIVEPOINTER This cookie contains the value of the store ID of the session. This value is used to select the store to execute the command, if one is not specified on the URL. WC_USERACTIVITY_ID For example: WC_USERACTIVITY_-1000
This is a user session cookie that flows between the browser and server over both SSL or non-SSL connection. It is used for user identification over non-SSL connections. It contains user session values such as login timeout, session identifier, etc. WC_GENERIC_ACTIVITYDATA This cookie only exists if it is a generic user (-1002) session. This cookie stores the session values such as storeid, langid, contracts, etc. WC_AUTHENTICATION_ID For example: WC_AUTHENTICATION_-1000
WebSphere Commerce uses a secure authentication cookie to manage authentication data. An authentication cookie flows only over SSL, and has a timestamped signature for increased security. This cookie is used to authenticate the user over SSL-connections.
Store-level session management
The following diagram illustrates the WebSphere Commerce store level registration infrastructure and user session management in a multi-store environment. Store level registration uses access control roles to associate a customer with a store.
Store level registration
Users that shop at a store do not necessarily need to be a member of the store's organization but need to play a shopping role (that is, Registered Customer) in the organization. Users that play an administrative role in an organization are usually associated with the organization by having an ancestral relationship with the organization.
For example, suppose that you have a store, Store A as in the preceding diagram. Also suppose that Sue shops at Store A and Joe is an employee for Store A responsible for the administrative duties of running Store A.
To model this scenario from an organizational perspective, Joe should be placed under the Store A's organization but Sue should not. As Sue is not an employee of Store A, Sue is associated with Store A by having her play the shopping role in the Store A organization.
A store determines all of its registered customers by finding all the users that play a shopping role in the store's organization. A user administrator of the store can then proceed to perform store wide activities such as setting up a campaign for all the registered users in a store, or specific actions such as resetting the password of a user registered to its store.
Referring to the previous diagram, consider the following scenario:
- Sue, who is a member of the Default Organization, has a shopping role in Reseller A's organization.
- Reseller A's parent organization is the Reseller Organization.
- Reseller A owns store A.
- Sue does not have an organizational role in Reseller B's organization.
- Reseller B owns store B.
- Sue logs into Store A and shops as usual.
- When Sue accesses Store B, Sue is assigned a new session identity for Store B as a guest user.
- If she accesses Store A once again, the information in her previous session identity for Store A is used by WebSphere Commerce to manage her session.
- The session identity for Store A would be reused for Store B if:
- Store A and Store B belong to the same organization.
- Sue has a role defined in both the Reseller A and Reseller B organizations.
- Use cookies for session management
Use the Configuration Manager to enable cookies for session management.
- Use URL rewriting for session management
Use the Configuration Manager to specify how sessions should be managed.
- Use JSP pages for URL rewriting
To use URL rewriting to maintain session state, do not include links to parts of the Web application in plain HTML files. This restriction is necessary because URL encoding cannot be used in plain HTML files.To maintain state using URL rewriting, every page that the user requests during the session must have code that can be understood by the Java interpreter. If you have such plain HTML files in the Web application and portions of the site that the user might access during the session, convert them to JSP files.
- Set the expiration time of the referral cookie
Setting the expiration time enables you to change the tracking behavior of the referral cookie. The referral cookie is used for marketing activities, to track the URL that referred the customer to the WebSphere Commerce site. That is, it tracks the URL that was displayed in the customer's browser immediately before navigating to the WebSphere Commerce site.