Introduction to Web Forms State Management
Web pages are recreated each time the page is posted to the server. In traditional Web programming, this would ordinarily mean that all information associated with the page and the controls on the page would be lost with 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 device to the server. For more information, see Web Forms Page Processing.
To overcome this inherent limitation of traditional Web programming, the ASP.NET page framework includes various options to help you preserve changes — that is, for managing state. The page framework includes a facility called view state that automatically preserves property values of the page and all the controls on it between round trips. However, you will probably also have application-specific values that you want to preserve. To do so, you can use one of the state management options.
Some of the options involve keeping information on the client — for example, directly in the page or in a cookie — and others involve storing information on the server between round trips. Each option has distinct advantages and disadvantages.
Client-Based State Management Options
The following sections describe options for state management that involve storing information either in the page or on the client computer. For these options, no information is maintained on the server between round trips.
The Control.ViewState property provides a dictionary object for retaining values between multiple requests for the same page. This is the method that the page uses 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. When the page is posted back to the server, the page parses the view state string at page initialization and restores property information in the page.
Hidden Form Fields
ASP.NET allows you to use HTML-standard hidden fields in a form. A hidden field does not render visibly in the browser, 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 field acts as a repository for any page-specific information that you would like 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.
A hidden field stores a single variable in its value property and must be explicitly added to the page. Then you insert your value into the hidden field. ASP.NET provides the HtmlInputHidden control that offers hidden field functionality. For more information see ASP.NET Server Controls by Function.
In order for hidden field values to be available during page processing, you must submit the page using an HTTP post method. That is, you cannot take advantage of hidden fields if a page is processed in response to a link or HTTP GET method. For usage recommendations, see State Management Recommendations.
A cookie is a small amount of data stored either in a text file on the client's file system or in-memory in the client browser session. It contains page-specific information the server sends to the client along with page output. Cookies can be temporary (with specific expiration times and dates) or persistent.
Security Note The browser can only send the data back to the server that originally created the cookie. However, malicious users have ways to "steal" cookies and read their contents. It is recommended that you do not store sensitive information in a cookie, such as a user name or password. Instead, store a token that you can use to look up the sensitive information on the server.
A query string is information appended to the end of a page's URL. A typical example might look like the following:
In the URL path above, the query string starts with the question mark (?) and includes two attribute-value pairs, one called "category" and the other called "price."
Query strings provide a simple but limited way of maintaining some state information. For example, they are an easy way to pass information from one page to another, such as passing a product number from one page to another page where it will be processed. However, most browsers and client devices impose a 255-character limit on the length of the URL.
Security Note Information 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. For more information, see Scripting Exploits.
In order for query string values to be available during page processing, you must submit the page using an HTTP get method. That is, you cannot take advantage of a query string if a page is processed in response to an HTTP post method. For usage recommendations, see State Management Recommendations.
Server-Based State Management Options
ASP.NET offers you a variety of ways to maintain state information on the server, as described in the following sections.
ASP.NET allows you to save values using application state (an instance of the HttpApplicationState class) for each active Web application. Application state is a global storage mechanism accessible from all pages in the Web application and is thus useful for storing information that needs to be maintained between server round trips and between pages. For more information, see Application State.
Application state is a key-value dictionary structure created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests.
Once you add your application-specific information to application state, the server manages it. For usage recommendations, see State Management Recommendations.
Session state is similar to application state, except that it is scoped to the current browser session. If different users are using your application, each will have a different session state. In addition, if the same user leaves your application and then returns later, that user will also have a different session state.
Session state is structured as a key-value dictionary structure for storing session-specific information that needs to be maintained between server round trips and between requests for pages. For more information, see Session State.
Session state enables you to:
- Uniquely identify browser or client-device requests and map them to an individual session instance on the server.
- Store session-specific data on the server for use across multiple browser or client-device requests within the same session.
- Raise appropriate session management events. In addition, you can write application code leveraging these events.
Once you add your application-specific information to session state , the server manages this object. Depending on what options you specify, session information can be stored in cookies, an out-of-process server, or a SQL Server. For usage recommendations, see State Management Recommendations.
Maintaining state using database technology is a common practice when storing user-specific information where the information store is large. Database storage is particularly useful for maintaining long-term state or state that must be preserved even if the server must be restarted.
The database approach is often used in conjunction with cookies. For example, when a user first accesses your application, you might have the user log in. You can look up the user in your database and then pass a cookie to the user. The cookie might contain only the ID of the user in your database (for example, a customer number). You can then use the cookie in subsequent requests to find the user information in the database as needed.
The database support approach enables you to:
- Uniquely identify browser or client-device requests and map them to a unique ID.
- Maintain state by relating stored information to the unique ID. You can use the unique ID to query the database for information relating to that ID. You can then modify the information and save it back to the database for use across multiple requests for the same — or different — pages in your site.
- Raise appropriate events. A condition in the database may determine site action. For example, if the user of a commerce site attempts to purchase something that is not in stock, a database query may signal that the Web site should prompt the user to make another selection.
For more information on using a database to maintain state, see State Management Recommendations.
Web Forms State Management | Saving Web Forms Page Values Using View State | State Management Recommendations | Page Members | ASP.NET State Management | Application State | Session State | HttpCookie Class