Skip to main content

Session Management

WATCH & LEARN0:50 · Animated tutorial
7 scenesPlay, pause, or scrub at your own pace

Wisej.NET manages application state on the server for each browser session, keeping that state available across requests and browser refreshes.

Web Session Basics​

Web systems are inherently stateless:

  • Each browser request may be processed by different server threads
  • Server threads can be reused across browsers
  • Session management requires generating and tracking session IDs with each request

Wisej.NET fully supports server-side state management for both HTTP and WebSocket connections.

info

Contrast this with other frameworks:

  • Blazor lacks native state management - refreshing loses all work
  • Angular, React and similar client-side libraries don't support sessions
  • ASP.NET offers limited HTTP-only session control (not WebSocket compatible) using shared cookies

Understanding Sessions​

Important distinctions:

  • Sessions differ from users and authentication
  • Web sessions parallel desktop application instances
  • Desktop apps can run with/without users/authentication
  • Multiple instances create separate sessions
  • Web apps don't run separate executables per session
  • No dedicated UI thread exists
  • Each request independently restores session state

Session Challenges​

Web applications face unique session management challenges:

  • Browser and server on different machines
  • Intermittent connectivity
  • Users leaving browsers open
  • Unexpected shutdowns
  • Navigation between pages
  • Browser refresh/F5

A session should survive temporary interruptions but eventually end when the user leaves. Because the server cannot reliably distinguish browser closure, device shutdown, and navigation away from the application, Wisej.NET uses:

Timeout​

Wisej.NET monitors inactivity to determine when a session should expire. The sessionTimeout setting controls when it raises Application.SessionTimeout, giving the application a chance to respond before the session is removed.

danger

When a session times out, it's permanently removed - like terminating a desktop application. ASP.NET's Session_End handler in Global.asax fires after session removal, allowing only cleanup.

Handle Application.SessionTimeout to respond before the session and the user's work are lost. If the event is not handled, Wisej.NET displays its built-in countdown window.

After another timeout period without user response, Wisej.NET removes the session and fires Application.ApplicationExit.

Keep-Alive​

Beyond sessionTimeout, Wisej.NET employs a keep-alive ping system that triggers after periods of user inactivity. This helps detect when users are "gone" due to:

  • Closed browser
  • Powered-off device
  • Lost connectivity

With no user activity but an open browser, the client sends keep-alive messages. Without these messages, Wisej.NET terminates the session after sessionTimeout * 2.

Countdown Window​

After sessionTimeout seconds without user interaction, Wisej.NET:

  1. Fires Application.SessionTimeout
  2. Shows built-in SessionTimeoutForm if unhandled
Default timeout window.

You can:

  • Show a custom window
  • Extend SessionTimeoutForm
  • Show nothing by setting e.Handled = true
Application.SessionTimeout += Application_SessionTimeout;

private static void Application_SessionTimeout(object sender, System.ComponentModel.HandledEventArgs e)
{
    // do something
    
    // suppress the built-in timeout window.
    e.Handled = true;
}

Infinite Sessions​

Wisej.NET supports two types of infinite sessions:

  1. Standard Infinite
    • Suppress the timeout window
    • Session stays alive while browser is open and connected
    • See above for suppressing timeout window
tip

Best practice: Set sessionTimeout to 1-3 minutes (60-180 seconds) and handle Application.SessionTimeout to control expiration notices or suppress them entirely.

  1. Browser-Bound Sessions
    • Bind session to browser by saving Session ID to local storage
    • Optionally set sessionTimeout to 0 (never expires until server shutdown)
    • Users can return later to continue where they left off
    • Requires controlled session count

Session ID Storage​

Traditional HTML systems (PHP, ASP.NET, JSP) store session IDs in cookies that:

  • Persist after browser closure
  • Share across browser tabs
  • Limit to one session per browser

Wisej.NET offers two storage options:

Session Storage (Default)​

Wisej.NET defaults to browser Session Storage:

  • Cleared when browser closes
  • Not sent in request headers
  • Unique per browser tab
info

Closing the browser clears the stored session ID. The server detects the missing keep-alive messages and removes the server-side session according to the timeout rules described above.

Local Storage​

Optionally configure Wisej.NET to use browser Local Storage:

  • Survives browser closure/device shutdown
  • Session reloads automatically if not expired
  • Continues work from previous state

Session Termination​

Various scenarios affect session termination:

Application Exit​

If your application provides exit options, call Application.Exit() to:

Browser Events​

These scenarios stop keep-alive pings, triggering session termination after sessionTimeout * 2:

  • Closing browser tab
  • Closing entire browser
  • Navigating away
  • Device shutdown
info

Browsers provide no way to distinguish between navigation, closure, shutdown, or device destruction. All appear the same to the server.