Application.ClientId seems to be renewed when opening/closing a browser window

[itg-assistant]

Uwe Fritsche asked 2025-12-12 15:35:52 UTC

For identifying users who accidently closed the browser window - using the Application.ClientId helped to identify their application session. Since a couple of weeks we receive "error reports" from customers that this behaviour doesn't work anymore. When debugging with Wisej 3.5.6 and Wisej 4.0.3 - using MS Edge, Firefox and Chrome - the outcome was that indeed the **Application.ClientId **changed when closing and re-opening any browser. What is the cause of this behaviour and how can it be "fixed"?

[itg-assistant]

Julie (ITG) answered 2025-12-12 16:19:34 UTC

The Application.ClientId is stored in the browser's LocalStorage. The reason you're seeing ClientId changing after closing and reopening the browser is most likely due to recent browser privacy changes.
Modern browsers (Chrome, Edge, Firefox) have been implementing stricter privacy measures, including:

• Storage partitioning - Browsers are now partitioning localStorage by top-level site to prevent cross-site tracking

• Third-party cookie blocking - Browsers are increasingly blocking or limiting third-party cookies and storage access

Solutions

1. Use Cookie-Based Storage Instead
   You can store your own client identifier in cookies rather than relying solely on Application.ClientId:

// At application start, check for existing client ID in cookies
var existingClientId = Application.Cookies["MyClientId"];
if (string.IsNullOrEmpty(existingClientId))
{
// Generate and store a new client ID
var newClientId = Guid.NewGuid().ToString();
Application.Cookies.Add("MyClientId", newClientId);
}

2. Configure Session Storage to Use LocalStorage
   In your Default.json, ensure you have the session storage set to "local":

{
"sessionStorage": "local"
}

This allows the session to survive browser closure, but may still be affected by browser privacy settings. See https://docs.wisej.com/docs/concepts/configuration for more information

3. Implement User Authentication
   The most reliable approach is to implement proper user authentication. When users log in, you can associate their session with their user account in your database, making browser storage irrelevant for session recovery:

// After successful login
Application.Session.UserId = authenticatedUserId;
// Store session info server-side linked to the user

4. Check Browser Settings with Users
   Have affected users check their browser settings for:

• "Clear cookies and site data when you close all windows" (in Chrome: Settings → Privacy and Security)

• Any browser extensions that clear storage data

Hope this helps,

Julie

[itg-assistant]

Uwe Fritsche answered 2025-12-12 17:22:17 UTC

Thanks a lot - we'll try out your proposals ASAP.

[itg-assistant]

Uwe Fritsche answered 2025-12-15 18:29:54 UTC

Solution 1 seems to work for us. Cookies in web browsers are still functional with several current web browser implementations.

Thank you Julie.