How To Create A User Session Using Cookies
Browsers and e-commerce sites use HTTP to communicate. HTTP is a stateless protocol, which means that each command is run independently without any knowledge of the commands that came before it. Because it is a stateless protocol, sessions must be managed between the browser side and the server side. With cookie-based session management, a message (cookie) containing user 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. The cookie allows the server to identify the user and retrieve the user session from the session database, so that the user session is maintained. A cookie-based session ends when the user logs off or closes the browser. Cookie-based session management is secure and has performance benefits over alternatives. For this reason, cookie-based session management is recommended for customer sessions.
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.
- an HCL Commerce session cookie is internal to HCL Commerce and does not persist to the database. All the cookies persist to memory except the persistent cookie. This configuration is the default. This configuration is required if URL rewriting is enabled.
- Secure authentication cookie
Used to manage authentication data. An authentication cookie flows over SSL and is time-stamped for maximum security. This cookie is used to authenticate the user whenever a sensitive command is run. For example, the
DoPaymentCmd, which asks for a user credit card number. There is minimal risk that this cookie might be stolen and used by an unauthorized user. Authentication code cookies are always generated by HCL Commerce whenever cookie-based session management is in use.
Important:
- Prior to 9.1.6.0, the
WC_AUTHENTICATIONandWC_IdentitySignaturecookies were the only cookies with the secure attribute set. -
All session cookies now have the secure attribute set. This enhanced behavior can be disabled, but it is not recommended.
Both the session and authentication code cookies are required to view secure pages.
For cookie errors, the CookieErrorView is called:
- When the user logs in from another location with the same Logon ID, and multiple logon is not enabled.
- When the cookie is corrupted, tampered with, or both.
- If cookie acceptance is set to
trueand the user browser does not support cookies.
Warning: Some browsers have features that preserve session cookies across browser sessions. One example is the Continue where I left off option that is provided by Google Chrome. Although these configurations are non-default, and require users to explicitly enable them, they can create privacy concerns when the browser is used in a public setting such as an Internet Cafe.
If the browser is configured to not destroy session cookies when it is closed, the cookies that are used for user identification and authentication remain active after the browser is restarted. In the case of a registered user, the user remains logged in. In the case of a guest user, all the assets that are associated to the user, such as pending carts, orders, or addresses, remain associated to the session in the browser. This behavior is caused by the browser not destroying session cookies, and it affects all sites that are accessed from the browser in the same way.
The default configuration for HCL Commerce is that when a user registers or logs in, the assets that are associated to the guest user before they login are transferred to the registered user account. These assets include addresses, orders, and interest items. This scenario might be a concern if the browser is shared and if it is configured to not destroy session cookies upon closure. For example, a guest user might place an order and close the browser. The following day, a different person might open the same browser and log in. Because the guest user session remains active, its assets, including the order that is placed and addresses used, are associated with the registered user that logged in.
The following options are available to avoid this scenario:
- Customize the MigrateUserEntriesCmd command, which is used to migrate addresses, orders and interest items from the current guest user session to the user that logs in. You can customize the command so that certain assets are not copied by replacing the method with an empty implementation.
- After a guest user places an order, automatically issue the Logoff command to reset the guest user session to the generic user.
Preserved session cookies to not present the same concern for registered users because these shoppers can use the Logoff link to clear their session information.
Browsers running on personal or mobile devices, such as phones or tablets, have the same issues as shoppers who use a browser in a public setting. These types of devices are not typically shared, so they do not present the same privacy concerns. However, shoppers on personal or mobile devices do not typically end the browser application after they browse a site, so session cookies are not destroyed. The options that are provided for protecting the privacy of shoppers in a public setting also apply to browsers that run on personal or mobile devices.
Aurora starter store cookies
The following table lists Aurora starter store cookies.
| Cookie name | Description |
|---|---|
| analyticsFacetAttributes | The list of facets that the customer clicked, making this data available to the analytics tags in those pages. The cookie is continually updated until the customer starts a new search or starts a new session. |
| analyticsPreCategoryAttributes | Pre-category attributes used for Analytics. |
| analyticsSearchTerm | Search terms used for Analytics. |
| CompareItems_storeId | Catalog Entry IDs that are being compared. |
| priceMode | Display mode for showing prices in the storefront. |
| searchTermHistory | The history of terms searched. |
signon_warning_cookie | Error key that is used to retrieve error messages. |
| WC_CartOrderId_storeId | Active Order Id for the store. |
| WC_CartTotal_orderId | Subtotal of order items (before tax and shipping), number of items, language, currency. |
| WC_DeleteCartCookie_storeId | Cookie to force refresh of other Mini Shopping Cart cookies. |
| WC_physicalStores | Physical stores that customer selects. |
| WC_pickUpStore | Pick-up store ID that customer selects. |
| WC_recurringOrder_orderId | Recurring order ID. |
| WC_ScheduleOrder_orderId_interval | Scheduled orders interval. |
| WC_shipTypeValue | Shipping type value: single or multiple. |
| WC_shipTypeValueOrderId | The orderId that corresponds to the Shipping type. |
| WC_SHOW_USER_ACTIVATION_storeId | Flag to show user activation message after user registration. |
| WC_OnBehalf_Role_storeId | Cookie to track the role of the user who started an on behalf session. |
| WC_Base_Text_Direction | This cookie is created when a shopper sets the Text Direction in the Language and Currency panel. The cookie can be used in HTTP and HTTPS.
|
How To Create A User Session Using Cookies
Source: https://help.hcltechsw.com/commerce/9.1.0/admin/concepts/csesmsession_mgmt_cookies.html
Posted by: powellagar1989.blogspot.com

0 Response to "How To Create A User Session Using Cookies"
Post a Comment