Web Store Sessions
This topic describes how domain bridging works in your SuiteCommerce or SuiteCommerce Advanced (SCA) web store. The type of domain bridging (encrypted domain bridging or domain bridging) depends on your web store implementation and whether it has customizations that are incompatible with encrypted domain bridging. Encrypted domain bridging is used on SuiteCommerce and most SCA implementations but some SCA implementations use domain bridging without encryption.
This topic applies to web store implementations that use separate shopping and checkout domains but not to those that use a single domain. For more information about domains and NetSuite, see Set Up Domains for Web Stores.
If your online store uses a separate, non-secure web store domain linked to a secure checkout domain, the two domains hold different types of information related to the same website session:
-
Non-secure HTTP web store domain: Supports non-secure content and shopping pages.
-
Secure HTTPS checkout domain: Supports secure content and checkout and My Account pages.
Both environments are deeply integrated into NetSuite and do not have access to state or session information from the other environment. To achieve a seamless customer experience between secure and non-secure domains, tokens and linkable attributes are passed between the two server environments through URL parameters and are stored as cookies to maintain the transferred state over time on each domain. This process is commonly referred to as domain bridging.
When encrypted domain bridging is used, the URL parameters are also encrypted.
NetSuite never sends credentials such as user names and passwords from a non-secure HTTP domain and always uses the secure HTTPS domain for authentication.
Domain bridging does not transfer any data about the user’s browser or computer. The data exchanged relates to the user’s shopping state like user cart, used promotion codes, and chosen shipping information.
Session Management
A Commerce web store uses a combination of entities and roles to manage website session information stored on and across domains.
Definitions:
-
Entity: An entity is the identifier for a specific NetSuite user. An entity is typically of the type Customer, but can be other types including Vendor or Employee.
-
Role: A role is assigned to a user and includes sets of permissions for viewing and editing data. Roles and their associated permissions determine the pages that users can see and the tasks that they can perform.
-
Session: A website session (open browser tab) is defined by the server environment to track the state associated with the current user experience in NetSuite. A session tracks both the
EntityIDand theRoleassociated with the user.
Explicit Session Invalidation
Explicit session invalidation is used to enhance website security and applies to all SuiteCommerce, SCA, and Site Builder web stores.
Changes that are made to a user’s credentials during an active website session can result in session invalidation for that user. If the user’s credentials (including their password, whether the assigned role exists, and whether a user is active) are changed, explicit session invalidation occurs and the session ends.
The following examples describe explicit session invalidation scenarios:
-
If a website administrator changes a user’s password, all existing sessions for that user end. If the user was logged in to an active session, they are automatically logged out and must log in to your website again.
-
If a user initiates a password reset (for example, using a Forgot My Password link), all existing sessions for that user end.
-
If a logged-in user changes their password in the My Account area of your website, their session in that browser tab continues. However, any other existing sessions end.
-
If a user’s role changes, all existing sessions for that user end. This includes changing the role by a script and explicitly removing one role and adding another.
Roles
The following two NetSuite roles are used with Commerce web stores:
Shopper Role
The Shopper role is used for a website user who is not authenticated and does not have a Customer Center role. Any time a user visits your website, their session is assigned a Shopper role by default if no other role can be established by a prior login.
The Shopper role has read-only permissions that are limited to record types in your NetSuite account, such as items. With a Shopper role, users cannot take any action to create a new record, other than registering as a customer.
Because of how the Shopper role is used in Commerce web stores, some functionality is not supported. For example, the newsletter functionality is currently not supported in Commerce web stores because a user with the Shopper role cannot directly create a new lead record.
Customer Center Role
The Customer Center role determines the information shown in the My Account section of your website and the login access permissions given to your customers. All new customers are automatically assigned this role after they register as customers.
The Customer Center role provides elevated permissions for records, such as transactions, that are required to create the Checkout and My Account experiences. This role can be customized with different levels of access. For example, you can remove access to transactions or records, or limit access to view-only instead of editing or creating records.
For more information about the Customer Center role, see Create the Website Customer Center Role.
Session States
A session state indicates the degree of authentication that the server understands about the current website user. A session state is managed throughout the life of the user's website session and is determined by the combination of entity and role awareness.
Commerce web stores support the following three session states:
-
Anonymous state - A session is considered anonymous when the web store knows nothing about the user. The user does not have an Entity ID defined. An anonymous session state typically occurs when someone visits your website for the first time, but can also occur after a customer has signed out. Anonymous users have full permissions for the unsecured HTTP shopping domain. For example,
EntityID: 0andRole: Shopper. Anonymous users also have limited access to the secure HTTPS checkout and My Account domains so that they have the ability to log in. -
Authenticated state - A user is considered authenticated when they are in a website session that has been logged in. A logged-in session means that the server environment knows both the Entity ID of the user and their associated role. For example,
EntityID: 1234andRole: Customer Center. -
Recognized state - A user is considered recognized when the server environment knows their Entity ID but they do not have a valid website session. For example, the user's role is Shopper instead of Customer Center. The recognized session state typically occurs when a customer who has logged in before returns to your website later. For example,
EntityID: 1234andRole: Shopper.
The following table provides examples of session states:
|
Session State |
EntityID |
Role |
Degree of Authentication |
|---|---|---|---|
|
Authenticated |
1234 |
Customer Center |
User is currently logged in. |
|
Recognized |
1234 |
Shopper |
User has logged in some time in the past. |
|
Anonymous |
0 |
Shopper |
User is unknown and is likely a first-time visitor. |
|
IMPOSSIBLE |
0 |
Customer Center |
Authentication cannot occur. |
Sign In
If an anonymous user tries to access the secure HTTPS checkout or My Account domains, they are required to log in or create an account and can only view the login or register page.
If an anonymous user signs in or creates an account on the secure HTTPS domain, their role is elevated from the Shopper role to the Customer Center role and an Entity ID is assigned. However, this only occurs on the secure HTTPS domain.
After logging in to the secure domain, the user's role and entity state has not yet changed on the unsecured HTTP domain. For the unsecured domain to be in sync with the secure domain, the user needs to return to the unsecured domain and, through the link, pass the appropriate information to sync the secure session's information. After the unsecured domain is in sync, the user then has the same Entity ID (1234) and elevated role (Customer Center) on both server environments.
Cookies
The following cookies are used to retain website session information specific to the Commerce web store experience:
-
NLShopperID - This cookie is used for encrypted domain bridging and links a specific browser to a specific cart. It resides in the browser and persists beyond the current browsing session. The value of this cookie is kept in sync between servers and determines how returning customers are later recognized.
-
CkID/ShopperID - These cookies are used for domain bridging without encryption and link a specific browser to a specific cart. They reside in the browser and persist beyond the current browsing session. The values of these cookies are kept in sync between servers and determine how returning customers are later recognized.
-
JSESSIONID - This cookie links a specific browser to a specific session on one of the NetSuite servers. If the shopping experience spans both the unsecured HTTP shopping domain and the secure HTTPS checkout or My Account domains, a different
JSESSIONIDis associated with each domain.
Shopping Cart Use Case
If a user visits a web store for the first time on their work computer (Session 1 in the following example), they are issued an NLShopperID cookie that identifies the specific browser and computer being used and references the shopping cart.
If domain bridging is not encrypted, the user is issued a ShopperID cookie instead of an NLShopperID cookie.
After the user goes to the checkout page, the HTTP shopping domain requests a secure domain bridging URL. The domain bridging URL uses encrypted parameters to transfer information about the user’s browser, computer, and their cart to the HTTPS checkout domain. The user, browser, and cart connection between the two NetSuite server environments is preserved to create a single unified experience.
If domain bridging is not encrypted, the HTTP shopping domain passes the ShopperID to the HTTPS checkout domain through the CkID cookie. This cookie identifies the user’s browser and computer and its association with the user’s cart.
If a user later logs in to your website from another computer or a different browser (Session 2 in the following example), they are issued a new NLShopperID cookie. The pre-existing cart and the new cart are merged and associated with the new NLShopperID cookie and the user’s EntityID.
If domain bridging is not encrypted and a user later logs in to your website from another computer or a different browser, a different CkID is passed. The pre-existing cart and the new cart are merged and associated with the new CkID cookie and the user’s EntityID.
Example: Session 1 (Work Computer)
A new user who has never visited your site goes to your web store. They are not recognized and are assigned an EntityID of 0 and the default Shopper role. At the same time, a shopping cart is created (CartID: 10000) and associated with the NLShopperID cookie. However, because the user has not created an account, the EntityID for the shopping cart is 0.
If domain bridging is not encrypted, a CkID cookie is created along with the shopping cart and is associated with the newly created CartID.
Next, the user goes to the secure domain, intending to log in or register. The NLShopperID and CartID cookies are passed from the shopping environment using an encrypted parameter in the domain bridging link, and the checkout domain starts off with the same attributes as the shopping server. Because the session's role is Shopper, the user is presented with a login or register page.
If domain bridging is not encrypted, the CkID cookie is passed from the shopping environment along with the CartID.
After the user creates an account on the secure HTTPS checkout domain, the shopping cart on the checkout domain is associated with the newly created EntityID: 1234, resulting in a direct link between the shopping cart and the customer.
Example: Session 2 (Home Computer)
The same user leaves work and goes home. At home, they decide to return to your web store on their home computer. When they return to your web store, they are not recognized and are considered a new user with an EntityID of 0 and the default Shopper role.
Next, the user goes to the secure HTTPS checkout domain, intending to log in. The NLShopperID cookie is passed from the shopping environment using an encrypted parameter in the domain bridging link, and the checkout domain starts off with the same attributes as the shopping server. Because the session's role is Shopper, the user is presented with a login or register page.
If domain bridging is not encrypted, the CkID cookie is passed from the shopping environment, and the checkout domain starts off with the same attributes as the shopping server.
The user signs back into their account with the new credentials they created earlier at work. After the user logs in, the system recognizes an existing cart with the same EntityID and updates NLShopperID to refer to the existing CartID. If the user added items on their home computer and their cart contained items when they shopped at work, then the items added from home are merged with the original cart and the user’s session information is updated.
If domain bridging is not encrypted, the system recognizes an existing cart with the same Entity ID and updates CkID to refer to the existing CartID.
More than one NLShopperID (or CkID, if domain bridging is not encrypted) can be associated with a single cart. This is how NetSuite synchronizes carts between work, home, and mobile devices.