Session Management

Wisej.NET has an extensive session management system. It's probably the most complete server-side state management compared to other web frameworks.

Web systems are stateless by nature: each request coming from the browser may be processed by a different thread on the server, and the same thread may be reused by another browser. The only way to support server-side sessions is to generate a session ID and pass it along with every request. Wisej.NET fully supports server-side state management for both HTTP and WebSocket connections.

Blazor doesn't support any real state management natively - just hit refresh on a Blazor app and everything you are working on is lost. Angular, React and other client-side scripting libraries don't support sessions. ASP.NET supports sessions with limited control only using HTTP (not supported with WebSocket) and saving a cookie shared among tabs.

Don't confuse "user" with "authentication" with "session". A web session is similar to a desktop application instance. You can run a desktop app with or without a user or an authentication. When you start a second instance of the same executable, you get a second "session". The web application doesn't run any executable for each session, there is no UI thread running: each request is independent from the previous and must restore the session associated with the browser making the request.

In a web application the browser and the server are on different machines and usually far apart; they can lose and regain connectivity, the user can just leave the browser on and go home, or can turn it off without terminating the application, navigate to another page and back, hit refresh (or F5), etc.

The session must survive some of these events and terminate for others. Since there is absolutely no way to detect when a browser is closed, or a device turned off, and even distinguish a simple navigation from closing a tab, there is only one efficient way to manage a server-side lifetime: keep-alive pings and the session timeout.

Timeout

This is the number of seconds that Wisej.NET waits, without any sign that the user is alive, before removing the session from memory.

When the session times out, it's disposed, gone, removed, deleted. Cannot be recovered. It's like terminating a desktop application. ASP.NET only provides the Session_End handler in Global.asax; it fires when the session is gone, all you can do is clean up.

The sessionTimeout setting in Wisej.NET is the number of seconds, without any sign the user is alive, before Wisej.NET fires the Application.SessionTimeout event. It gives you a chance to react before the session and the user's work is lost. By default, if you don't handle the Application.SessionTimeout event, Wisej.NET shows a built-in countdown window.

After the same timeout period, if the user still has not reacted, Wisej.NET removes the session and fires the Application.ApplicationExit event.

Keep-Alive

In addition to the sessionTimeout, Wisej.NET uses a keep-alive ping system. It fires a keep-alive event after a certain timeout when the user is not interacting with the application.

Since the user cannot interact with the application if the browser is closed, or the device turned off, or the connectivity is lost, the keep-alive system is useful to detect when the user is "gone".

If there is no user activity (ie the user is staring at the screen), but the browser is still open, the client (browser) sends a keep-alive message to the server. However, if the browser is closed. no keep-alive message is sent.

If Wisej.NET doesn't receive any "signal" from the browser it will terminate the session after sessionTimeout * 2.

Countdown Window

Regardless of the keep-alive system, after sessionTimeout seconds without any user interaction, Wisej.NET fires the Application.SessionTimeout event and, if not handled by the application, it shows the build-in SessionTimeoutForm.

Default timeout window.

You can show your custom window, or use SessionTimeoutForm as the base for your modified version, or show nothing at all. Simply set e.Handled = true to suppress the built-in window.

C#

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;
}

VB.NET

AddHandler Application.SessionTimeout, AddressOf Application_SessionTimeout

Public Sub Application_SessionTimeout(sender As Object, e As HandledEventArgs)

    ' Do something.
    
    ' Suppress the built-in timeout window.
    e.Handled = True

End Sub

Infinite Sessions

Wisej.NET also supports the concept of "Infinite Sessions". In fact there are two kinds of infinite sessions. The most common is to simply suppress the timeout window and, as long as the browser is open and there is connectivity, keep the application alive. See above how to suppress the timeout window.

Our recommendation is to set the sessionTimeout to a low number: 1-3 minutes (60-180 seconds) and handle the Application.SessionTimeout to control what to show to the user when their session is about to expire - or simply suppress the expiration notice.

Another, less used, approach to support infinite sessions is to bind the session to a browser by saving the Session ID to the local storage, and you can optionally set the sessionTimeout to 0. When the sessionTimeout is set to 0, the session never expires (until the server is turned off).

With this approach, if the number of sessions is controlled, a user can close the browser, come back another day and find the same state he or she left and can restart working exactly where they left off.

Session ID

HTML systems like PHP, ASP.NET, JSP store the session ID in a cookie which is then returned to the server in the header of each HTTP request. Cookies can persist after the browser is closed and are always shared among browser tabs (you cannot start more than 1 session with the same browser.)

Wisej.NET instead stores the session ID in the browser's Session Storage. or optionally in the Local Storage (see sessionStorage in Configuration).

Session Storage

This is the default location where Wisej.NET saves the Session ID. It's wiped out when the browser is closed, it's not sent to the server in the request headers, and each browser tab has its own.

👉 If you close the browser and reopen it, your session is gone.

Local Storage

You can optionally configure Wisej.NET to store the Session ID in the browser's local storage. In this case, it survives closing the browser or turning off the machine. When you reopen the browser, if your session hasn't expired, you will find your previous state reloaded in the browser automatically and will be able to keep working where you left off.

Closing

Closing what? You can close the browser tab, close the browser, turn off the device (or throw it out the window), lose power, lose connectivity, forget the computer on for a week, navigate to another web page, or click the Logout or Terminate button - if they are provided by the Wisej.NET application you are using.

Application

If your application provides an "Exit" option and/or any other rule or requirement to terminate a session, call Application.Exit(). It will immediately free the session and fire the Application.ApplicationExit event.

Browser Tab

When the user closes the browser tab (or navigates away) the keep-alive pings stop, after sessionTimeout * 2 Wisej.NET will terminate the session.

Entire Browser

When the user closes the entire browser (or navigates away) the keep-alive pings stop, after sessionTimeout * 2 Wisej.NET will terminate the session.

Burning the device

When the user destroys the device (or navigates away) the keep-alive pings stop, after sessionTimeout * 2 Wisej.NET will terminate the session.

There is no difference (to the browser) between navigating, closing, turning off or burning the device. (Please don't contact support asking how to detect that the browser was closed, it's impossible regardless of what some blogger may write.)