Dr. Dobb's | Two Ways to Create Unique Session IDs

Two Ways to Create Unique Session IDs

ASP.NET sessions can be tracked either by using cookies or generating a modified URL

March 24, 2003
URL:http://www.drdobbs.com/two-ways-to-create-unique-session-ids/184416823

COM Objects from ASP.NET Pages

Each active ASP.NET session is identified by using a 120-bit string of URL-allowed characters. The 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 SessionID string is communicated to the browser, then returned to the server application in either of two ways: using cookies or a modified URL. By default, the session state module creates an HTTP cookie on the client, but (especially for cookieless browsers) a modified URL can be used with the SessionID string embedded. Which approach is taken depends on the configuration settings stored in the application's web.config file. To configure session settings, you use the <sessionState> section. The structure of the section is shown below:

<sessionState mode="Off | InProc | StateServer | SQLServer"
   cookieless="true | false"
   timeout="number of minutes"
   stateConnectionString="tcpip=server:port"
   sqlConnectionString="sql connection string" />

By default, the cookieless attribute is false, meaning that cookies are used by browsers and the web server to exchange session information. A cookie is really nothing more than a text file placed on the client's hard disk by a web page. In ASP.NET, a cookie is represented by an instance of the HttpCookie class. Typically, a cookie has a name, a collection of values, and an expiration time. In addition, you can configure the cookie to operate on a particular virtual path and over secure connections (i.e., HTTPS).

When the cookieless attribute is set to False, which is the default, the session state module actually creates a cookie with a particular name and stores the session ID in it. The cookie is created as the following pseudocode shows:

HttpCookie sessionCookie;
sessionCookie = new HttpCookie("ASP.NET_SessionId", 
sessionID);
sessionCookie.Path = "/";

ASP.NET_SessionId is the name of the cookie and the SessionID string is its value. The cookie is also associated with the root of the current domain. The Path property describes the relative URL that the cookie applies to. A session cookie is given a very short expiration term and is renewed at each successful request end. The cookie's Expires property indicates the time of day on the client at which the cookie expires. If not explicitly set, as is the case with session cookies, the Expires property defaults to DateTime.MinValue, which is the smallest possible unit of time in the .NET Framework.

A server-side module that needs to write a cookie adds an HttpCookie object to the Response.Cookies collection. Cookies associated with the requested domain are also available for reading through the Request.Cookies collection.

The session ID is generated using the Random Number Generator (RNG) cryptographic provider. The service provider returns a 15-byte-long sequence (15x8=120 bit) of randomly generated numbers. Each number identifies a byte. The cryptographic provider can generate a sequence of random bytes of any length. A session ID is 15 bytes long by design. The array of bytes is then encoded to URL valid characters and returned as a string.

Finally, note that if the session contains nothing, then a brand new session ID is generated per each request and the session state is not persisted to the state provider.

Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Magazine and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].