10.3 Session State

10.3 Session State

Maintaining state on behalf of each client is often necessary in Web applications, whether it is used to keep track of items in a shopping cart or to note viewing preferences for a particular user . ASP.NET provides three ways of maintaining client-specific state: session state, cookie state, and view state. Each technique has its advantages and disadvantages. Session state is the most flexible and, in general, the most efficient. ASP.NET has enhanced session state to address some of the problems associated with it in previous versions of ASP, including the abilities to host session state out of process (or in a database) and to track session state without using cookies.

Session state is maintained on behalf of each client within an ASP.NET application. When a new client begins to interact with the application, a new session ID (or session key) is generated and associated with all subsequent requests from that same client (either using a cookie or via URL mangling). By default, the session state is maintained in the same process and AppDomain as your application, so you can store any data type necessary in session state. If you elect to house session state in another process or in a database, however, there are restrictions on what can be stored, as we will discuss shortly. Session state is maintained in an instance of the HttpSessionState class and is accessible through the Session property of both the Page and HttpContext classes. When a request comes in to an application, the Session properties of the Page and HttpContext class used to service that request are initialized to the current instance of HttpSessionState that is associated with that particular client. Listing 10-3 shows the primary methods and properties of the HttpSessionState class, along with the property accessors in both the Page and HttpContext classes.

Listing 10-3 HttpSessionState Class

public sealed class HttpSessionState : ICollection,
                                       IEnumerable
{
    // properties
  public int CodePage {get; set;}
  public int Count {get;}
  public bool IsCookieless {get;}
  public bool IsNewSession {get;}
  public bool IsReadOnly {get;}
  public KeysCollection Keys {get;}
  public int LCID {get; set;}
  public SessionStateMode Mode {get;}
  public string SessionID {get;}
  public HttpStaticObjectsCollection StaticObjects {get;}
  public int Timeout {get; set;}
    // indexers
  public object this[string] {get; set;}
  public object this[int] {get; set;}
    // methods
  public void Abandon();
  public void Add(string name, object value);
  public void Clear();
  public void Remove(string name);
  public void RemoveAll();
  public void RemoveAt(int index);
  //...
}

public class Page : TemplateControl, IHttpHandler
{
  public virtual HttpSessionState Session {get;}
  //...
}

public sealed class HttpContext : IServiceProvider
{
  public HttpSessionState Session {get;}
  //...
}

Because the HttpSessionState class supports string and ordinal-based indexers, it can be populated and accessed using the standard array access notation that most developers are familiar with from traditional ASP. There are some new properties, however, including flags for whether the session key is being maintained with cookies or with mangled URLs ( IsCookieless ) and whether the session state is read-only ( IsReadOnly ). Also note that although the CodePage property is accessible through session state, this is for backward compatibility only. The proper way to access the response's encoding is through Response.ContentEncoding.CodePage .

For an example of using session state, let's consider an implementation of the classic shopping cart for a Web application. As a user navigates among the pages of an application, she selects items to be retained in a shopping cart for future purchase. When the user is done shopping, she can navigate to a checkout page, review the items she has collected in her cart, and purchase them. This requires the Web application to retain a collection of items the user has chosen across request boundaries, which is exactly what session state provides. Listing 10-4 shows the definition of a class called Item . Instances of this class are used to represent the selected items in our shopping cart.

Listing 10-4 Item Class

public class Item
{
  private string _description;
  private int    _cost;

  public Item(string description, int cost)
  {
    _description = description;
    _cost = cost;
  }

  public string Description
  {
    get { return _description; }
    set { _description = value; }
  }
  public int Cost
  {
    get { return _cost; }
    set { _cost = value; }
  }
}

To store Item instances on behalf of the client, we initialize a new ArrayList in session state and populate the ArrayList with items as the client selects them. If you need to perform one-time initialization of data in session state, the Session_Start event in the Application class is the place to do so. Listing 10-5 shows a sample handler for the Session_Start event in our application object, which in our case is creating a new ArrayList and adding it to the session state property bag indexed by the keyword "Cart" .

Listing 10-5 Initializing Session State Objects

// in global.asax
public class Global : System.Web.HttpApplication
{
  protected void Session_Start(Object sender, EventArgs e)
  {
    // Initialize shopping cart
    Session["Cart"] = new ArrayList();
  }
}

A sample page that uses the shopping cart is shown in Listings 10-6 and 10-7. In this page, two handlers are defined: one for purchasing a pencil and another for purchasing a pen. To keep things simple, the items and their costs have been hard-coded, but in a real application this information would normally come from a database lookup. When the user elects to add an item to her cart, the AddItem method is called. This allocates a new instance of the Item class and initializes it with the description and cost of the item to be purchased. That new item is then added to the ArrayList maintained by the Session object, indexed by the string "Cart" . Listings 10-8 and 10-9 show a sample page that displays all the items in the current client's cart along with a cumulative total cost.

Listing 10-6 Session State Shopping Page Example

<! File: Purchase.aspx >
<%@ Page language="c#" Codebehind="Purchase.aspx.cs"
         Inherits="PurchasePage" %>

<HTML>
  <body>
    <form runat="server">
      <p>Items for purchase:</p>
      <asp:LinkButton id=_buyPencil runat="server"
                      onclick="BuyPencil_Click">
           Pencil ()</asp:LinkButton>
      <asp:LinkButton id=_buyPen runat="server"
                      onclick="BuyPen_Click">
           Pen ()</asp:LinkButton>
      <a href="purchase.aspx">Purchase</a>
    </form>
  </body>
</HTML>

Listing 10-7 Session State Shopping Page Example ”Code-Behind

// File: Purchase.aspx.cs
public class PurchasePage : Page
{
  private void AddItem(string desc, int cost)
  {
    ArrayList cart = (ArrayList)Session["Cart"];
    cart.Add(new Item(desc, cost));
  }

  // handler for button to buy a pencil
  private void BuyPencil_Click(object sender, EventArgs e)
  {
    // add pencil () to shopping cart
    AddItem("pencil", 1);
  }

  // handler for button to buy a pen
  private void BuyPen_Cick(object sender, EventArgs e)
  {
    // add pen () to shopping cart
    AddItem("pen", 2);
  }
}

Listing 10-8 Session State Checkout Page Example

<! File: Checkout.aspx >
<%@ Page language="c#" Codebehind="Checkout.aspx.cs"
         Inherits="CheckoutPage" %>
<HTML>
 <body>
 <form runat="server">
   <asp:Button id=Buy runat="server" Text="Buy"/>
   <a href="purchase.aspx">Continue shopping</a>
 </form>
 </body>
</HTML>

Listing 10-9 Session State Checkout Page Example ”Code-Behind

// File: Checkout.aspx.cs
public class CheckOutPage : Page
{
  private void Page_Load(object sender, System.EventArgs e)
  {
      // Print out contents of cart with total cost
      // of all items tallied
    int totalCost = 0;

    ArrayList cart = (ArrayList)Session["Cart"];
    foreach (Item item in cart)
    {
      totalCost += item.Cost;
      Response.Output.Write("<p>Item: {0}, Cost: </p>",
                             item.Description, item.Cost);
    }

    Response.Write("<hr/>");
    Response.Output.Write("<p>Total cost:
// File: Checkout.aspx.cs public class CheckOutPage : Page { private void Page_Load(object sender, System.EventArgs e) { // Print out contents of cart with total cost // of all items tallied int totalCost = 0; ArrayList cart = (ArrayList)Session["Cart"]; foreach (Item item in cart) { totalCost += item.Cost; Response.Output.Write("<p>Item: {0}, Cost: ${1}</p>", item.Description, item.Cost); } Response.Write("<hr/>"); Response.Output.Write("<p>Total cost: ${0}</p>", totalCost); } }

</p>",
                          totalCost);
  }
}

The key features to note about session state are that it keeps state on behalf of a particular client across page boundaries in an application, and that the state is retained in memory on the server in the default session state configuration.

10.3.1 Session Key Management

To associate session state with a particular client, it is necessary to identify an incoming request as having been issued by a given client. A mechanism for identifying a client is not built into the essentially connectionless HTTP protocol, so client tracking must be managed explicitly. In traditional ASP, this was always done by setting a client-side cookie with a session key on the first client request. This technique is still supported in ASP.NET (in fact, it is the default technique) and is demonstrated in Figure 10-1.

Because session keys are used to track clients and maintain potentially sensitive information on their behalf, they must not only be unique, they must also be next to impossible to guess. This has been a problem in the past when programmers used Globally Unique Identifiers (GUIDs) as session keys. Because the original algorithm for generating GUIDs was deterministic, if you knew one of the GUIDs generated by a server machine, you could guess subsequent GUIDs and thus access the session state associated with another client. Although GUIDs are no longer generated this way, ASP.NET takes the precaution of generating its own session keys by using the cryptographic service provider and its own encoding algorithm. Listing 10-10 shows some pseudocode demonstrating the technique used by ASP.NET for creating session keys.

Listing 10-10 Session Key Generation in ASP.NET

// Generate 15-byte random number using the crypto provider
RNGCryptoServiceProvider rng =
                         new RNGCryptoServiceProvider();
byte[] key = new byte[15];
rng.GetBytes(key);

// Encode the random number into a 24-character string
// (SessionId is a private class - not accessible)
string sessionKey = SessionId.Encode(key);

Using cookies to track session state can be problematic . Clients can disable cookie support in their browsers, and some browsers do not support cookies. As an alternative to using cookies, ASP.NET also supports a technique called URL mangling to track session keys without using client-side cookies. This technique works by intercepting the initial request made by a client, inserting the session key into the URL, and redirecting the client to the original page requested . When this page receives the request, it extracts the encoded session key from the request URL and initializes the current session state pointer to the correct block of memory. This technique is demonstrated in Figure 10-2. This technique works even with clients that have disabled cookie support in their browsers. On any subsequent navigation, either via anchor tags or explicit programmatic redirections, ASP.NET will alter the target URL to embed the session key as well. This implicit URL mangling works only for relative URLs, however, so care must be taken with all links in an application using cookieless session key management to avoid absolute URLs.

Controlling whether cookies or URL mangling is used to manage your session keys (along with several other session state “ related features) is performed through the sessionState element in your application's web.config file. Table 10-2 lists the various configuration settings available for the sessionState element of web.config . Listing 10-11 shows a sample web.config file that enables cookieless session key management for an application.

Table 10-2. sessionState Attributes

40

<configuration>
  <system.web>
    <sessionState cookieless="true" />
  </system.web>
</configuration>

[Serializable]
public class Item
{
  private string _description;
  private int    _cost;
  // ...
}

<configuration>
  <system.web>
    <sessionState mode="StateServer"
       stateConnectionString="192.168.1.103:42424"
    />
  </system.web>
</configuration>

CREATE TABLE tempdb..ASPStateTempSessions (SessionId        CHAR(32) NOT NULL PRIMARY KEY,
  Created          DATETIME NOT NULL DEFAULT GETDATE(),
  Expires          DATETIME        NOT NULL,
  LockDate         DATETIME        NOT NULL,
  LockCookie       INT             NOT NULL,
  Timeout          INT             NOT NULL,
  Locked           BIT             NOT NULL,
  SessionItemShort VARBINARY(7000) NULL,
  SessionItemLong  IMAGE           NULL,)

<configuration>
  <system.web>
    <sessionState mode="SQLServer"
     sqlConnectionString=
        "data source=192.168.1.103;user id=sa;password=" />
  </system.web>
</configuration>