Managing Client State

Applications need to maintain state for either user- or application-specific data. There are three techniques for managing client state in ASP.NET: Session, ViewState, and Cookies. Session state stores user data on the ASP.NET server and relies upon a session ID assigned to the user. The user presents the session ID on subsequent requests, and the user’s data is available within Session for the duration of that request. ViewState stores user or application data in the response of the HTML that is sent back to the user in hidden <form> variables. Cookies are small chunks of data that can be stored on the user’s computer and are sent with each request to the application.

• Use in-process session state (the default) if you have only a single server. In IIS 6, either use out-of-process session state or disable process recycling behavior to avoid data loss.

• Don’t use the Session_End event; it can be called only for sessions created in the InProc mode. The event is not raised for sessions created in one of the out-of-process modes when sessions are abandoned.

• It’s important to note that the programming model is transparent. For example, we don’t have to change how we access or use session state when we change the storage mode.

• We recommend SQL Server for out-of-process session state because it is just as fast as StateServer, and SQL Server is excellent at managing data.

• Store only basic data types when using out-of-process session state; avoid storing complex types or custom classes. Storing basic data types will decrease the serialization and deserialization costs associated with out-of-process session as well as reduce the complexity of the system.

• If the server running the state service is accessible outside the firewall, the port address of the state service should be changed to a value other than the default. In version 1.1 of ASP.NET, due to security reasons, only local machines can connect to the state server. To allow only non–local host requests in ASP.NET 1.1, open the same registry entry listed earlier for the port setting: HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\. Change AllowRemoteConnection to 1.

• For ASP.NET 1.0, configure SQL Server for mixed-mode authentication by adding the ASPNET account enabled for the necessary SQL Server permissions (EXECUTE) for ASP.NET session state. (The ASPNET account is the user that the ASP.NET worker process runs as.) For ASP.NET 1.1 running on IIS 6, configure SQL Server for mixed- mode authentication by adding the NT AUTHORITY\NETWORK SERVICE account.

• Use integrated authentication rather than store SQL Server credentials within your configuration file. If you decide to use SQL Server user names and passwords, do not use the system administrator (sa) account. Instead use an account that has only the necessary access to the database object required for the operations (for session state, this account is EXECUTE only). If you must use SQL Server credentials, ASP.NET 1.1 supports storing credentials securely.

• Ensure SQL Server Agent is running before running the Session state installation SQL Scripts. The agent runs a periodic job to purge expired sessions from the database.

• For out-of-process session, set session state to enableSessionState=“false” within the configuration file, and set the EnableSessionState page directives to either true or ReadOnly based on what behavior is needed. Note that the length of the session will still be reset (even when set to false). This will prevent unnecessary round trips when Session state is not needed.

• Using the SessionID as a key for user data is not recommended. The SessionID is randomly generated, and session data—as well as session IDs—do expire. Additionally, although a SessionID might be generated on each request, a SessionID is set only when a Session value is set server-side. This means that if no session values are set server side, new SessionIDs are issued on each request.

• If you have to develop an application that supports both cookie and cookieless sessions, your best strategy is to write an HTTP module to redirect the browser to the appropriate application or server for the supported browser feature; for example, configure a dedicated application that is used for cookieless sessions.

• A Message Authentication Code (MAC) is a key-dependent, one-way hash. A MAC is used to verify ViewState data by recomputing the MAC on postback and comparing it to the MAC stored in __VIEWSTATE. If the MACs match, the data in __VIEWSTATE is valid. If they do not match, the ViewState data is invalid and an exception is thrown.

• The view state can be disabled in a page by using <%@ Page EnableViewState=“false” %>, or in a control by specifying Page.EnableViewState=“false” on the server control.