• Choose a category
• All
• Classic-Fiction

By Root 5358 0

new class and implement the interface from the ground up, or inherit a new class from SessionIDManager and override a couple of virtual methods to apply some personalization. The first option offers maximum flexibility; the second is simpler and quicker to implement, and it addresses the most compelling reason you might have to build a custom session ID generator—to supply your own session ID values.

Let’s start by reviewing the methods of the ISessionIDManager interface, which are shown in Table 17-13.

Table 17-13. Methods of the ISessionIDManager Interface

Method

Description

CreateSessionID

Virtual method. It creates a unique session identifier for the session.

Decode

Decodes the session ID using HttpUtility.UrlDecode.

Encode

Encodes the session ID using HttpUtility.UrlEncode.

Initialize

Invoked by the session state immediately after instantiation; performs one-time initialization of the component.

InitializeRequest

Invoked by the session state when the session state is being acquired for the request.

GetSessionID

Gets the session ID from the current HTTP request.

RemoveSessionID

Deletes the session ID from the cookie or from the URL.

SaveSessionID

Saves a newly created session ID to the HTTP response.

Validate

Confirms that the session ID is valid.

If you plan to roll your own completely custom session ID generator, bear in mind the following points:

The algorithm you choose for ID generation is a critical point. If you don’t implement strong cryptographic randomness, a malicious user can guess a valid session ID when the same session is still active, thus accessing some user’s data. (This is known as session hijacking.) A good example of a custom session ID algorithm is one that returns a globally unique identifier (GUID).

You can choose to support cookieless sessions or not. If you do, you have to endow the component with the ability to extract the session ID from the HTTP request and redirect the browser. You probably need an ISAPI filter or HTTP module to preprocess the request and enter appropriate changes. The algorithm you use to store session IDs without cookies is up to you.

If you are absolutely determined to have the system use your session IDs, you derive a new class from SessionIDManager and override two methods: CreateSessionID and Validate. The former returns a string that contains the session ID. The latter validates a given session ID to ensure it conforms to the specification you set. After you have created a custom session ID module, you register it in the configuration file. Here’s how to do it:

sessionIDManagerType="Samples.MyIDManager, MyLib" />

Session State Performance Best Practices

State management is a necessary evil. By enabling it, you charge your application with an extra burden. To reduce the performance impact of session state on Web applications, the first guideline is to disable session state whenever possible. However, to prevent the session from expiring, the HTTP module still marks the session as active in the data store. For out-of-process state servers, this means that a roundtrip is made. Using a custom session ID manager returning a null session ID for requests that are known not to require session state is the best way to work around this issue and avoid the overhead entirely. (Write a class that inherits from SessionIDManager and overrides GetSessionID.)

The second guideline entails minimizing contention on session data by avoiding frames and downloadable resources served by session-enabled handlers.

The third guideline relates to data serialization and deserialization. You should always use simple types and break complex classes into arrays of simple properties, at least as far as session management is concerned. In other words, I’m not suggesting that you should factor out your DAL classes—just change the way you serialize them into the session store. An alternate approach entails building a custom serialization algorithm that is optimized for session state storage. Breaking