Customizing Session State Management

Since its beginning, the ASP.NET session state was devised to be an easy-to-customize and extensible feature. All things considered, you have the following three options to customize session state management:

You can stay with the default session state module but write a custom state provider to change the storage medium (for example, to a non–SQL Server database or a different table layout). In doing so, you also have the chance to override some of the helper classes (mostly collections) that are used to bring data from the store to the Session object and back.

You can stay with the default session state module but replace the session ID generator. But hold on! The algorithm that generates session IDs is a critical element of the application, because making session IDs too easy for attackers to guess can lead straight to session-hijacking attacks. Nonetheless, this remains a customizable aspect of session state that, properly used, can make your application even more secure.

You can unplug the default session state module and roll your own. This option, however, should be used as a last resort. Obviously, it provides the maximum flexibility, but it is also extremely complicated and is recommended only if strictly necessary and if you know exactly what you’re doing. We won’t cover this topic in the book.

The first option—the easiest and least complicated of all—addresses most of the scenarios for which some custom session management is desirable. So let’s tackle it first.

Building a Custom Session State Provider

A session state provider is the component in charge of serving any data related to the current session. Invoked when the request needs to acquire state information, it retrieves data from a given storage medium and returns that to the module. Invoked by the module when the request ends, it writes the supplied data to the storage layer. As mentioned, ASP.NET supports three state providers, as listed in Table 17-11.

Table 17-11. Default State Providers

Name

Class

Storage Medium

InProc

InProcSessionStateStore

Stores data as live objects in the ASP.NET Cache.

StateServer

OutOfProcSessionStateStore

Stores data as serialized objects to the memory of a Windows service named aspnet_state.exe.

SQLServer

SqlSessionStateStore

Stores data as serialized objects into a SQL Server database.

You can write your own state provider class that uses the storage medium of your choice. Note that the default state providers also make use of various helper classes to move data around. In your custom provider, you can replace these classes too, or just stick to the standard ones.

Defining the Session State Store

A state provider (also often referred to as a session state store) is a class that inherits from SessionStateStoreProviderBase. The main methods of the interface are listed in Table 17-12.

Table 17-12. Methods of the SessionStateStoreProviderBase Class

Method

Description

CreateNewStoreData

Creates an object to contain the data of a new session. It should return an object of type SessionStateStoreData.

CreateUninitializedItem

Creates a new and uninitialized session in the data source. The method is called when an expired session is requested in a cookieless session state. In this case, the module has to generate a new session ID. The session item created by the method prevents the next request with the newly generated session ID from being mistaken for a request directed at an expired session.

Dispose

Releases all resources (other than memory) used by the state provider.

EndRequest

Called by the default session state module