• Choose a category
• All
• Classic-Fiction

Methods of the HttpSessionState Class

Table 17-6 shows all the methods available in the HttpSessionState class. They mostly relate to typical operations on a collection. In this sense, the only exceptional method is Abandon, which causes the session to be canceled.

Table 17-6. HttpSessionState Methods

Method

Description

Abandon

Sets an internal flag that instructs the session module to cancel the current session.

Add

Adds a new item to the session state. The value is boxed in an object type.

Clear

Clears all values from the session state.

CopyTo

Copies the collection of session-state values to a one-dimensional array, starting at the specified index in the array.

GetEnumerator

Gets an enumerator to loop through all the values in the session.

Remove

Deletes an item from the session-state collection. The item is identified by the key.

RemoveAll

Calls Clear.

RemoveAt

Deletes an item from the session-state collection. The item is identified by position.

When the procedure to terminate the current request is running, the session-state module checks an internal flag to verify whether the user ordered that the session be abandoned. If the flag is set—that is, the Abandon method was called—any response cookie is removed and the procedure to terminate the session is begun. Notice, though, that this does not mean that a Session_End event will fire.

First, the Session_End event fires only if the session mode is InProc; second, the event does not fire if the session dictionary is empty and no real session state exists for the application. In other words, at least one request must have been completed for the Session_End to fire when the session is closed either naturally or after a call to Abandon.

Working with a Session’s State

Now that you have grabbed hold of the session state basics, you can sharpen your skills by looking into more technically relevant aspects of session state management. Handling session state is a task that can be outlined in three steps: assigning a session ID, obtaining session data from a provider, and stuffing it into the context of the page. As mentioned, the session state module governs the execution of all these tasks. In doing so, it takes advantage of a couple of additional components: the session ID generator and session state provider. In ASP.NET, both can be replaced with custom components, as we’ll discuss later. For now, let’s tackle some of the practical issues you face when working with session state.

Identifying a Session

Each active ASP.NET session is identified using a 120-bit string made only of URL-allowed characters. Session IDs are guaranteed to be unique and randomly generated to avoid data conflicts and prevent malicious attacks. Obtaining a valid session ID algorithmically from an existing ID is virtually impossible. The generator of the session ID is a customizable system component that developers can optionally replace.

Note

An old proverb reminds us that nothing should be done only because it is doable. This motto is particularly apt here as we talk about parts of the session state management that are customizable in ASP.NET. These subsystems, such as the session ID generator, should be customized only when you have a good reason to and only when you’re certain it won’t make things worse or lower the level of security. I’ll return to this point in a moment with more details.

Generating the Session ID

A session ID is 15 bytes long by design (15x8 = 120 bits). The session ID is generated using the Random Number Generator (RNG) cryptographic provider. The service provider returns a sequence of 15 randomly generated numbers. The array of numbers is then mapped to valid URL characters and returned as a string.

If the session contains nothing, a new session ID is generated for each request and the session state is not persisted to the state provider. However, if a Session_Start handler is used, the session state is