ASP.NET.in.a.Nutshell.Second.Edition [Electronic resources] نسخه متنی

Chapter 19. The HttpSessionState Class

A significant challenge for any Web-based
application is managing user state. Unlike rich client applications,
in which user state can be stored in persistent variables local to
the client application, web browsers do not have a comparable
built-in facility for persistently storing user state locally. This
is because HTTP, the basic communication protocol used in web
applications, is essentially a connectionless protocol (the HTTP
specification allows persistent connections, but problems with
persistent HTTP connections prevent this specification from being
widely used). Each HTTP request/response is treated as completely
separate from every other request/response. As such, any local
variable storage cannot be reliably mapped from the request/response
in which they were created to any subsequent request/response.

An early solution to this challenge was the creation of cookies,
which are bits of text that are stored either in memory (per-session
cookies) or on disk (persistent cookies) and are associated with the
domain name from which they originated. This solves the problem of
being able to associate a bit of data with more than one
request/response, but it has limitations that made it a less than
ideal solution:

• Cookies can only
  store text (or a textual representation of other data), which means
  that cookie data cannot be made typesafe.

• Cookies are limited in size (the size limit depends on the browser,
  but is often 4k).

• Cookies can be manipulated on the client. If an application relying
  on cookies for user state does not take this into account, it is
  possible that a malicious user could use a manipulated cookie to
  breach the security of the application.

• Most browsers allow users to turn off or refuse cookies. If users do
  so, an application that relies on cookies for storing user state may
  not function correctly.

• Cookies present a potential performance and scalability problem,
  since all cookies for a given domain are sent with each
  request/response cycle. This means that sites making substantial use
  of cookies for state management will send a lot of information over
  the wire with each request/response cycle, whether that information
  is needed for that request/response or not.

For these reasons, classic ASP implemented state management through
the Session intrinsic object, which provided a collection of
key/value pairs for each user for storing user-specific state in
memory on the web server. In classic ASP, each user session was
identified by a unique identifier called the SessionID, which was
sent as a per-session cookie. This alleviated several concerns of
using cookies alone for storing user state, including the
performance/scalability issue and cookie size limits. However, it
still failed to address some issues, including the problem of users
who disable cookies. ASP.NET addresses this issue by allowing both
cookie-based and cookieless sessions, which are configurable at the
application level.

The HttpSessionState class is
ASP.NET's replacement for classic
ASP's Session intrinsic object. Like the other
classes that replace ASP intrinsics, HttpSessionState is exposed as a
property of the Page classin this case, the
Session property. Since each ASP.NET page inherits from the
Page class, these properties are available to any
code in the page. This means that migrating classic ASP code that
uses the Session object should be relatively painless.

The HttpSessionState class is used primarily for
storing and accessing data that is shared across all the pages
accessed by a particular user during a given session of interacting
with the application. The HttpSessionState class
provides properties and methods that map to the properties, methods,
and collections of the classic ASP Session object for backward
compatibility. It also adds a number of new properties and methods
that increase the convenience of dealing with session state.

As in classic ASP, each user session in ASP.NET is identified by a
unique SessionID, which is created at the same time as the
user's session, is exposed as a property of the
HttpSessionState class. In most cases, developers
do not need to concern themselves with this SessionID, since ASP.NET
handles it transparently.

A new SessionID is created the first time a user who does not have a
current session accesses a page within an ASP.NET application whose
session state has not been disabled by setting the
enableSessionState attribute of the
@ Page directive to
False. If the page stores information in the
Session collection, or if an event handler is defined for the
Session.Start event in the

global.asax file,
then a new session is created and the newly created SessionID is
assigned to that session. This delayed creation of the session until
it is actually used helps conserve the limited resources of the web
server and can help improve the scalability of ASP.NET applications.

When the session is created, the Session.Start event is fired. This
event can be handled by creating an event handler in the

global.asax file (the ASP.NET equivalent of

global.asa ) with the following signature:

Sub Session_OnStart( )
'Session initialization code
End Sub

By default, the lifetime of the session for a given user is 20
minutes from the time of the user's last request.
This setting is configurable at the application level via the ASP.NET

web.config configuration file or at the machine
level via the

machine.config configuration file.
Refer to Chapter 20 for more information on
configuring the session timeout value. When a session ends, either by
exceeding the timeout value or by code that calls the Session.Abandon
method, the Session.End event is fired. Like the Start event, you can
handle this event by adding an event handler to

global.asax with the following signature:

Sub Session_OnEnd( )
'Session cleanup code
End Sub

Note that the session does not end automatically when the user closes
their browser, so if you want to explicitly end the session when a
user is finished, you should implement some kind of logout feature
that calls the Session.Abandon method.

In ASP.NET, session state is managed through the
SessionStateModule
class, which is an HttpModule.
HttpModules are classes that derive from
IHttpModule and that participate in each HTTP
request in an ASP.NET application. The
SessionStateModule class is responsible for
generating and/or retrieving SessionIDs, firing the Start and End
events of the Session object, and abstracting the underlying Session
store from the HttpSessionState class.

Session state configuration is handled through the
sessionState configuration section of the

machine.config and

web.config configuration files. (The
sessionState configuration section of the
web.config configuration file will be discussed
in detail in Chapter 20.) The

machine.config file contains the default
settings for all applications on the machine, and may be overridden
by adding a sessionState section to the

web.config file for an application. If no
sessionState section appears in the
application-level configuration file, the defaults in

machine.config are inherited by the application.
As installed,

machine.config enables in-process
session state by using cookies to track the SessionID by default.

ASP.NET adds two new configuration options in addition to the timeout
value and enabling/disabling of sessions that were configurable in
classic ASP. The first provides built-in support for cookieless
sessions. Cookieless sessions are configured in the

web.config (or

machine.config ) file and implemented through the
SessionStateModule class, which automatically
modifies all relative URLs in the application and embeds the
SessionID, allowing the application to maintain user state without
using cookies. ASP.NET also provides the
Response.ApplyAppPathModifier method, which can create absolute URLs
containing the embedded SessionID given a virtual path to a resource.
This allows even applications to take advantage of cookieless
sessions by using absolute URLs.

The second new configuration option allows session state in ASP.NET
to span multiple servers through new out-of-process storage options.
ASP.NET state can now be stored in-process (the same as classic ASP),
in a special ASP.NET state NT service, or in a SQL Server database.
The latter two options allow multiple machines to use the same state
storage facility, albeit at the expense of making out-of-process
calls to set and retrieve state information. More importantly, all
storage options are transparent to the developer. Information is
added to and retrieved from the session state store in exactly the
same fashion, regardless of which underlying session state store is
used. This allows applications to be developed by initially using
in-process state storage for the best performance, and later moved to
out-of process storage to facilitate scaling out by adding more web
serversall without changing a single line of code in the
application.

Items can be stored in the Session collection in one of three ways:

• By calling the Add method, passing in the name to assign to the item
  and the item's value. This value can be of any type
  supported by the CLR, including object instances, which are
  automatically serialized before being stored. The Add method takes
  the form:

  Session.Add(itemName, itemValue)

• By explicitly referring to the Item property, passing a name or index
  to assign to the new item:

  Session.Item(itemName) = itemValue

• By implicitly referring to the Item property, passing a name to
  assign to the new item. This was the most common technique used in
  classic ASP.

  Session(itemName) = itemValue

Items in the Session collection can be accessed in one of three ways:

• By retrieving and iterating over the collection of keys in the
  Session collection (see the Keys collection description for an
  example).

• By explicitly referring to the Item property, passing the name of the
  item to retrieve:

  localVar = Session.Item(itemName)

• By implicitly referring to the Item property, passing the name of the
  item to retrieve. This was the most common technique used in classic
  ASP:

  localVar = Session(itemName)

Items can be removed from the Session collection in one of several
ways:

• By calling the Clear method (clears all items).

• By calling the RemoveAll method (removes all items, which is
  effectively the same as calling the Clear method).

• By calling the Remove method, passing the name of the item to remove.

• By calling the RemoveAt method, passing the index of the item to
  remove.

Table 19-1 lists the properties, collections,
methods, and events exposed by the
HttpSessionState class.

^[1] These events are exposed by the
SessionStateModule class, rather than the HttpSessionState
class.