Web Store Sessions
This topic describes how domain bridging works in your SuiteCommerce or SuiteCommerce Advanced (SCA) web store. The type of domain bridging you use (encrypted or not) depends on your web store setup and any customizations that might not work with encrypted domain bridging. SuiteCommerce and most SCA sites use encrypted domain bridging, but some SCA setups use domain bridging without encryption.
This topic applies to web store implementations that use separate shopping and checkout domains, not single-domain setups. For more information about domains and NetSuite, see Set Up Domains for Web Stores.
If your web store uses a separate, non-secure web store domain with a secure checkout domain, each one holds different information for the same 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 called domain bridging.
With encrypted domain bridging, the URL parameters are also encrypted.
NetSuite never sends usernames or passwords from a non-secure domain and always uses the secure domain for authentication.
Domain bridging doesn't transfer any information about the user's browser or computer. The data exchanged only relates to the user’s shopping state like user cart, used promotion codes, and chosen shipping information.
Session Management
A Commerce web store uses entities and roles to manage session information across domains.
Definitions:
-
Entity: This is the ID for a specific NetSuite user. It's usually a Customer, but can also be a Vendor or Employee.
-
Role: This is assigned to a user and sets what they can see or do in NetSuite.
-
Session: This is an open browser tab, and NetSuite uses it to track the user's EntityID and Role.
Explicit Session Invalidation
Explicit session invalidation helps keep your site secure and applies to all SuiteCommerce, SCA, and Site Builder web stores.
If a user's credentials change during an active session (like their password or role), explicit session invalidation kicks in and ends the session.
The following examples describe explicit session invalidation scenarios:
-
If a website administrator changes a user’s password, all their sessions 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 starts a password reset (like using the Forgot My Password link), all their sessions end.
-
If a logged-in user changes their password in My Account, their session in that tab continues, but any other sessions end.
-
If a user's role changes (including by script), all their sessions end.
Roles
The following two NetSuite roles are used with Commerce web stores:
Shopper Role
The Shopper role is for users who aren't logged in and don't have a Customer Center role. When someone visits your site, they're assigned the Shopper role by default unless they've logged in before.
The Shopper role has read-only permissions that are limited to record types in your NetSuite account, such as items. They can't create new records except for 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 controls what customers see in My Account and what they can access after registering. 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. You can customize this role to change or limit what customers can see or do.
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. It's managed during the user's session and depends on their entity and role.
Commerce web stores use three session states:
-
Anonymous state - The web store doesn't know who the user is (no entity ID). This usually happens when someone visits your site for the first time or after signing out. Anonymous users can use the unsecured shopping domain fully, but only have limited access to checkout and My Account so they can log in.
-
Authenticated state - The user is logged in, so the server knows their entity ID and role (EntityID: 1234 and Role: Customer Center).
-
Recognized state - The server knows the user's entity ID, but they're not logged in (EntityID: 1234 and Role: Shopper). This usually happens when someone who logged in before comes back later.
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 need 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 domain, their role changes from Shopper to Customer Center 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 haven’t changed yet on the unsecured domain. For the unsecured domain to 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 domains.
Cookies
The following cookies are used to retain website session information specific to the Commerce web store experience:
-
NLShopperID - This cookie is for encrypted domain bridging and links a browser to a cart. It stays in the browser even after you close it, and its value is kept in sync between servers to help recognize returning customers.
-
CkID/ShopperID - These cookies are for domain bridging without encryption. They link a browser to a cart, stick around after you close the browser, and are kept in sync between servers to recognize returning customers.
-
JSESSIONID - This cookie links a browser to a session on a NetSuite server. If you shop on both the unsecured and secure domains, each one gets its own JSESSIONID.
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're given an NLShopperID cookie that identifies the specific browser and computer being used and references the shopping cart.
If domain bridging isn't 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 isn't encrypted, the HTTP shopping domain passes the ShopperID to the HTTPS checkout domain through the CkID cookie. This cookie links the user's browser and computer to their cart.
If a user logs in from another computer or browser, they get a new NLShopperID cookie. The old cart and the new one are merged and linked to the new cookie and the user's EntityID.
If domain bridging isn't 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're 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 linked to the NLShopperID cookie. However, because the user hasn't created an account, the shopping cart's EntityID 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. Since the session's role is Shopper, the user sees 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 checkout domain, the shopping cart on the checkout domain is linked to the newly created EntityID: 1234, directly connecting the cart to 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're not recognized and are treated as 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 point to the existing CartID. IIf the user added items at home and their cart already had items from work, the system merges everything into the original cart and updates their session information.
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.
A single cart can have more than one NLShopperID (or CkID, if domain bridging isn't encrypted) linked to it. That's how NetSuite syncs carts between work, home, and mobile devices.