ASP.NET Session State Alternatives

Session variables are easy to use, but they could cause problems with scalability and security. By default, Session variables are stored in ASP.NET process (InProc mode is used). While this could work fine on websites with small traffic, on high traffic websites sessions will decrease performances. Things go worse if you increase session timeout too much, or store large objects in session variables.

Session variables are very easy to use and functional, so it's hard to persist and not use them. Bad reputation of session variables comes from classic ASP. Only possible mode for storage of session state in ASP 3.0 is inside of ASP process. Because of that, intensive use of session variables in classic ASP could cause dramatic degradation of performances. Also, if user doesn't support cookies, there is no easy way to make session works.

In ASP.NET, session state is improved a lot. As alternative to in process mode, now it is possible to store data to State Server or Sql Server which are more reliable and scalable solutions. You can even build custom session state provider to manipulate sessions according to your specific needs (like store sessions to MySQL, Oracle or some other database). Also, ASP.NET supports cookieless sessions, which automatically place session id in page URL.

So, in ASP.NET sessions are not evil. You just need to know all their options well and, depending of project requirements, be able to choose best option. But, in case that ASP.NET session state is not suitable for your next project, here are few possible alternatives:

Use cookies

Cookies are more scalable option than using sessions. Since all data are stored on client machine, memory on server remains free for other tasks. Instead of spending server resources like memory or database, ASP.NET will distribute data to visitors' computers.

If project requirements demand, cookies could persist after session expires. When the same visitor comes again after few days, you still can read variables saved on last visit.

To use cookies, users must have enabled them in their browsers. If user has older browser which doesn't support cookies, or is disabled cookies due to security reasons, this option will not work.

As one more disadvantage, be aware that cookies are very limited in size (4KB per cookie is maximum). You can use cookies to store some primitive types, but you can't place large objects in cookies. However, placing of large objects is not recommended in sessions too.

Also, storing of sensitive information in a cookie is security risk, because cookies can be read or maliciously changed by virus or any text editor on client machine, or captured while traveling between browser and web server. You can reduce risk if you encrypt values before store them in the cookie, or avoid using cookies for storing of sensitive information like passwords, login status etc. But, this encrypting/decrypting takes some time, which could cause decrease in performances.

Cookies must be sent to server for every request. Otherwise, ASP.NET can't read them. This cause additional bandwidth costs and slows down website. It is not big problem on PCs, because cookies have small size and almost everyone has fast Internet connection. 4KB is very small these days. But, mobile devices often have slow connection and this could be an issue if mobile devices are your target visitors. In this case, you can try to store larger amount of data somewhere on server side (e.g. in database or XML file) and keep just visitor's identification id in a cookie.

One more disadvantage of using cookies is that cookies could be deleted either by user, or automatically by browser. There is limited number of cookies which could be stored on client machine. Every web browser should accept 300 cookies, and max 20 cookies per domain. If number of cookies exceeds limit, oldest cookies will be deleted. So, for longer time periods, there is greater chance that your cookie will be deleted because it became oldest.

Use query strings

Query strings were common option to send data between pages. Even ASP.NET session state uses query string variable in URL if Cookieless parameter is set to true. So, query strings work if user is disabled cookies in browser.

Disadvantage of query strings is that you can't transfer a lot of data on this way. Query strings are usually used to transfer integers or short strings that represent some enumeration or identification id.

Also, you need to add query strings to any URL on page which could be tedious task. Using of master pages, or user controls can reduce work, but there is almost always some better way. In classic ASP, using of query strings was common way to solve communication between pages. This is one of the oldest ways to transfer data between pages. But, ASP.NET offers more options for data transfer which are faster to implement, and query strings are not used as much as before. If we also consider different methods of URL rewriting, I can even say that query strings are almost invisible in ASP.NET applications today.

Use ASP.NET ViewState

ASP.NET ViewState state stores information in page's HTML code, as hidden field named __VIEWSTATE. ViewState is also very scalable solution. Like in case when using cookies, information are stored on client side and don't load on server.

Unlike Session state, ViewState is designed to preserve data between postbacks on same page. You can't, at least by default, send data between pages using ViewState. There are some workarounds, you can, for example place some data to ViewState and then use Server.Transfer to load the second page. In this case, ViewState variables will be visible on second page so you practically transferred data between different pages using ViewState. But, on my personal opinion, this option looks ugly :).

With Server.Transfer method, you can also use Context.Items collection. Since two pages share same request, Context.Items collection is not destroyed and its variables will be visible on second page.

To send data to other page using ViewState, you can also use cross-postbacks or save page state to persistent medium. All these methods require additional efforts and are often complicated to implement in bigger applications.

Use hidden fields

You can place standard HiddenField control on web form and use its Value property to store user's data. This option is in essence almost identical to ViewState. Because of that, hidden field has the same advantages and disadvantages like ViewState. Since data are travelling between server and client for every request, hidden fields should be used only for small amount of data. If you place large data in hidden field, that could cause page to slow down.

Also, data are stored inside page HTML. That could be potential security risk. You can encrypt data, but that requires additional efforts. In old classic ASP applications, using of hidden fields was one of the possible ways to avoid using of sessions. In ASP.NET, hidden fields are not best options to replace sessions. Sessions are improved and not so evil, and also, we have better alternatives, like Profile properties.

Use Profile properties

Like Session state, profile properties save data of individual user. The important difference when compared to Session state is that Profile data remains after visitor leaves website and session expires. Because data are stored in Sql Server database by default, they are not affected on ASP.NET restart or even IIS restart. You can add custom providers to store data on other external stores, like XML files or other types of databases. Since data are stored out of process, Profile can be used on web farms and web gardens.

Data stored in Profile properties remain after session expires. This is considered as advantage. But, be aware that data will not be deleted automatically. Database will grow to keep data of every new visitor. So, you must implement mechanism in your application to clean old or unnecessary data in regular time intervals.

Use Forms Authentication, or session with session id only, and keep everything else in database

This is scalable method, which looks similar as mode="SQLServer". If security demands are high, you can use Forms Authentication or Windows Authentication to identify user. If information is public, Session id is enough. In this scenario, all data are stored in database, like strings, integers, serializable objects etc. Instead of database, you can also use XML file, or plain text file.

Information stored in database will stay there until you delete it. It will remain after web application restarts, recycle or session expires. This was very common method in ASP.NET 1.1. But, ASP.NET 2.0 and later includes Profile properties which practically do the same thing. Since Profile properties work with both authenticated and anonymous users and even support migrating of properties when user log in (event when anonymous user becomes authenticated), building your custom solution that uses database looks like reinventing the wheel.

Conclusion

Information stored in ASP.NET session state is considered as public. You should not use session for sensitive data. If your data should be safe, use Forms or Windows authentication with SSL.

ASP.NET Session state is improved a lot, when compared with old classic ASP sessions. Using of sessions in ASP 3.0 is often considered as bad programming habit. Improved ASP.NET session state offers more scalable and more reliable solutions, like using of Sql Server, State Server, or building your own custom session state provider where you have full control over sessions, including creating of session keys.

Although sessions in ASP.NET are more useful, they are not solution for every scenario. In this tutorial, you learned some alternatives to using session state. Most of them, like query strings, hidden fields or ViewState are rarely recommended option. As two best options for session state alternative in ASP.NET, you can use cookies or Profile properties.

Cookies could be a solution if you need to keep user's data between sessions and store data on client side. Session data are lost when session expires, but cookies could persist on user's computer. For example, that could be useful to check if visitor is first time on site (new visitor) or was on website before (returning visitor). If you write a cookie with current time, you will know time of last visit when she or he comes next time. Keep in mind that cookies could be deleted by browser, so they can't be used for any important data.

Cookies like sessions too, could be easily read. For sensitive information, better use Forms or Windows authentication. The most reliable way to keep user's information across sessions is to store them to database on server. You can do it manually, but it is usually more efficient to use Profile properties.

Profile properties also persist between sessions. Unlike cookies, data are stored on server side (in Sql Server database by default). Profile properties work with both authenticated and anonymous users and even support migrating of data when anonymous user log in.

Tutorial toolbar:  Tell A Friend  |  Add to favorites  |  Feedback  |   Google