Session State enables you to store information, which is persisted during page changes. It’s stored server-side, and is essentially a collection like ViewState, or Application state. The syntax is straightforward: Session[“Key”] = Value;
Session state is not shared between clients, like application state. Every user has his/her own session ID, which guaranteed (statistically) to be large enough not to be guessed or reverse-engineered.
To access his or her private session information, the user must provide the session ID. It can be stored two ways (just like the authentication information): in a cookie (ASP.NET_SessionId is the name) or in a modified URL, serving clients who don’t support cookies.
Using Session State:
To store a datatable in a user’s session, just type the following:
DataTable dt = new DataTable();
Session[“Cart”] = dt;
Retrieval is quite easy, too:
Dt = Sesion[“dt”] as DataTable;
Session state can be used in every page of your application, but it’s not immortal. Session information can be lost if:
- User closes/restarts browser.
- May be lost when the user requests the same page on a different browser window. The original page will have the session, but the new may not. This behavior depends on the browser.
- Timeout, due to inactivity. By default, it lasts 20 minutes.
- If you call Session.Abandon();
Sessions lost when the hosting application domain is recreated (e.g.: change a configuration file, recompile application). For a workaround for this situation, you can use out-of-process session management.
Configure Session State:
As always, use web.config, with the following snippet:
The possible attributes of session state are the following:
- Mode: enables you to choose a state provider. The values:
- Off: disables session state management. Use it when you want more memory, and don’t use sessions at all.
- InProc: in-process session state. Information is stored in the current AppDomain. Best performance, least durability. When hosting in a web farm environment, it won’t work.
- StateServer: information will be stored outside the default application domain, thus give a basic protection for it. Cost is increased time. When this setting is used, the address of the state server should be included to the stateConnectionString attribute.
- SQLServer: information will be stored in a SQL server database. Address should be specified in the sqlConectionString attribute. First use aspnet_regsql.exe to prepare the database. A limitation of this approach is that you can store only serializable values.
- Custom: use your custom state provider. This topic is rather advanced to the exam.
- Cookieless: set the usage of cookies. Possible values:
- UseCookies: cookies are always used, even if the browser doesn’t support them, or they are disabled.
- UseUri: same as usecookied, but the URL will be used to store the session ID.
- Timeout: set an expiration time in minutes. The default is 20.
Securing Session State:
The information of the session is secure, because it’s stored on the server. But an attacker may be able to access this information with a stolen cookie. Use SSL, and Request.Cookies[“ASP.NET_SessionId”].Secure = true;
To protect a user in cookiless mode, set the regenerateExpiredSessionId to true.