ASP.

NET State Management Overview

.NET Framework 4 Other Versions
A new instance of the Web page class is created each time the page is posted to
the server. In traditional Web programming, this would typically mean that all i
nformation associated with the page and the controls on the page would be lost w
ith each round trip. For example, if a user enters information into a text box,
that information would be lost in the round trip from the browser or client devi
ce to the server.
To overcome this inherent limitation of traditional Web programming, ASP.NET inc
ludes several options that help you preserve data on both a per-page basis and a
n application-wide basis. These features are as follows:
View state
Control state
Hidden fields
Cookies
Query strings
Application state
Session state
Profile Properties
View state, control state, hidden fields, cookies, and query strings all involve
storing data on the client in various ways. However, application state, session
state, and profile properties all store data in memory on the server. Each opti
on has distinct advantages and disadvantages, depending on the scenario.
Client-Based State Management Options
The following sections describe options for state management that involve storin
g information either in the page or on the client computer. For these options, n
o information is maintained on the server between round trips.
View State
The ViewState property provides a dictionary object for retaining values between
multiple requests for the same page. This is the default method that the page u
ses to preserve page and control property values between round trips.
When the page is processed, the current state of the page and controls is hashed
into a string and saved in the page as a hidden field, or multiple hidden field
s if the amount of data stored in the ViewState property exceeds the specified v
alue in the MaxPageStateFieldLength property. When the page is posted back to th
e server, the page parses the view-state string at page initialization and resto
res property information in the page.
You can store values in view state as well. For more information on using View S
tate, see ASP.NET View State Overview. For recommendations about when you should
use view state, see ASP.NET State Management Recommendations.
Control State
Sometimes you need to store control-state data in order for a control to work pr
operly. For example, if you have written a custom control that has different tab
s that show different information, in order for that control to work as expected
, the control needs to know which tab is selected between round trips. The ViewS
tate property can be used for this purpose, but view state can be turned off at
a page level by developers, effectively breaking your control. To solve this, th
e ASP.NET page framework exposes a feature in ASP.NET called control state.
The ControlState property allows you to persist property information that is spe
cific to a control and cannot be turned off like the ViewState property.
Hidden Fields
ASP.NET allows you to store information in a HiddenField control, which renders
as a standard HTML hidden field. A hidden field does not render visibly in the b
rowser, but you can set its properties just as you can with a standard control.
When a page is submitted to the server, the content of a hidden field is sent in
the HTTP form collection along with the values of other controls. A hidden fiel
d acts as a repository for any page-specific information that you want to store
directly in the page.
Security Note
It is easy for a malicious user to see and modify the contents of a hidden field
. Do not store any information in a hidden field that is sensitive or that your
application relies on to work properly. For more information, see ASP.NET State
Management Recommendations.
A HiddenField control stores a single variable in its Value property and must be
explicitly added to the page. For more information, see HiddenField Web Server
Control Overview.
In order for hidden-field values to be available during page processing, you mus
t submit the page using an HTTP POST command. If you use hidden fields and a pag
e is processed in response to a link or an HTTP GET command, the hidden fields w
ill not be available. For usage recommendations, see ASP.NET State Management Re
commendations.
Cookies
A cookie is a small amount of data that is stored either in a text file on the c
lient file system or in-memory in the client browser session. It contains site-s
pecific information that the server sends to the client along with page output.
Cookies can be temporary (with specific expiration times and dates) or persisten
t.
You can use cookies to store information about a particular client, session, or
application. The cookies are saved on the client device, and when the browser re
quests a page, the client sends the information in the cookie along with the req
uest information. The server can read the cookie and extract its value. A typica
l use is to store a token (perhaps encrypted) indicating that the user has alrea
dy been authenticated in your application.
Security Note
The browser can only send the data back to the server that originally created th
e cookie. However, malicious users have ways to access cookies and read their co
ntents. It is recommended that you do not store sensitive information, such as a
user name or password, in a cookie. Instead, store a token in the cookie that i
dentifies the user, and then use the token to look up the sensitive information
on the server.
For more information about using cookies, see Cookies and ASP.NET State Manageme
nt Recommendations.
Query Strings
A query string is information that is appended to the end of a page URL. A typic
al query string might look like the following example:
http://www.contoso.com/listwidgets.aspx?category=basic&price=100
In the URL path above, the query string starts with a question mark (?) and incl
udes two attribute/value pairs, one called "category" and the other called "pric
e."
Query strings provide a simple but limited way to maintain state information. Fo
r example, they are an easy way to pass information from one page to another, su
ch as passing a product number from one page to another page where it will be pr
ocessed. However, some browsers and client devices impose a 2083-character limit
on the length of the URL.
Security Note
Information that is passed in a query string can be tampered with by a malicious
user. Do not rely on query strings to convey important or sensitive data. Addit
ionally, a user can bookmark the URL or send the URL to other users, thereby pas
sing that information along with it. For more information, see ASP.NET State Man
agement Recommendations and How to: Protect Against Script Exploits in a Web App
lication by Applying HTML Encoding to Strings.
In order for query string values to be available during page processing, you mus
t submit the page using an HTTP GET command. That is, you cannot take advantage
of a query string if a page is processed in response to an HTTP POST command. Fo
r usage recommendations, see ASP.NET State Management Recommendations.
Server-Based State Management Options
ASP.NET offers you a variety of ways to maintain state information on the server
, rather than persisting information on the client. With server-based state mana
gement, you can decrease the amount of information sent to the client in order t
o preserve state, however it can use costly resources on the server. The followi
ng sections describe three server-based state management features: application s
tate, session state, and profile properties.
Application State
ASP.NET allows you to save values using application state which is an instance o
f the HttpApplicationState class for each active Web application. Application st
ate is a global storage mechanism that is accessible from all pages in the Web a
pplication. Thus, application state is useful for storing information that needs
to be maintained between server round trips and between requests for pages. For
more information, see ASP.NET Application State Overview.
Application state is stored in a key/value dictionary that is created during eac
h request to a specific URL. You can add your application-specific information t
o this structure to store it between page requests.
Once you add your application-specific information to application state, the ser
ver manages it. For usage recommendations, see ASP.NET State Management Recommen
dations.
Session State
ASP.NET allows you to save values by using session state which is an instance of
the HttpSessionState class for each active Web-application session. For an over
view, see ASP.NET Session State Overview.
Session state is similar to application state, except that it is scoped to the c
urrent browser session. If different users are using your application, each user
 session will have a different session state. In addition, if a user leaves your
application and then returns later, the second user session will have a differe
nt session state from the first.
Session state is structured as a key/value dictionary for storing session-specif
ic information that needs to be maintained between server round trips and betwee
n requests for pages. For more information, see ASP.NET Session State Overview.
You can use session state to accomplish the following tasks:
Uniquely identify browser or client-device requests and map them to an individua
l session instance on the server.
Store session-specific data on the server for use across multiple browser or cli
ent-device requests within the same session.
Raise appropriate session management events. In addition, you can write applicat
ion code leveraging these events.
Once you add your application-specific information to session state, the server
manages this object. Depending on which options you specify, session information
can be stored in cookies, on an out-of-process server, or on a computer running
Microsoft SQL Server. For usage recommendations, see ASP.NET State Management R
ecommendations.
Profile Properties
ASP.NET provides a feature called profile properties, which allows you to store
user-specific data. This feature is similar to session state, except that the pr
ofile data is not lost when a user's session expires. The profile-properties fea
ture uses an ASP.NET profile, which is stored in a persistent format and associa
ted with an individual user. The ASP.NET profile allows you to easily manage use
r information without requiring you to create and maintain your own database. In
addition, the profile makes the user information available using a strongly typ
ed API that you can access from anywhere in your application. You can store obje
cts of any type in the profile. The ASP.NET profile feature provides a generic s
torage system that allows you to define and maintain almost any kind of data whi
le still making the data available in a type-safe manner.
To use profile properties, you must configure a profile provider. ASP.NET includ
es a SqlProfileProvider class that allows you to store profile data in a SQL dat
abase, but you can also create your own profile provider class that stores profi
le data in a custom format and to a custom storage mechanism such as an XML file
, or even to a web service.
Because data that is placed in profile properties is not stored in application m
emory, it is preserved through Internet Information Services (IIS) restarts and
worker-process restarts without losing data. Additionally, profile properties ca
n be persisted across multiple processes such as in a Web farm or a Web garden.
For more information, see ASP.NET Profile Properties Overview.