Take the 2-minute tour ×

the other day I was discussing with a colleague and he came out saying that using user's session in a web application is just wrong. I replied that it could be wrong depending by the information you are storing, otherwise why should a web session service even being provided by Microsoft (we were talking about ASP.NET).

He replied to me, again, that even in MS they could easily reply me that it was bad design. And that he could show me some white-papers demonstrating that.

Unfortunately I have no opportunity to contact this guy anymore, but I would really like to understand more about his point of view. Does anyone have information/points of view about that here?

share|improve this question
The HTTP protocol was originally designed to be "stateless" - so that all transactions were singular, and based off the information provided. Sessions are a way of getting around that in some uses. Practically, though, for many modern websites, I can't think of a simple way you'd avoid sessions; maybe I'm not creative enough. –  Katana314 Jun 20 '13 at 14:04
@Katana314 Database storage with cookies. You can use sessions for very basic information like identifying the user, but a lot of session implementations (particularly in Django, which we've hit multiple times) have flaws that can create race conditions with more transient data whenever multiple requests by the same user are sent at once (like with AJAX calls) –  Izkata Jun 20 '13 at 18:24
Database storage with cookies is just a matter of housing your session in a database. –  Alan Shutko Jun 20 '13 at 18:53
add comment

3 Answers

I don't think he meant "Bad design" so much as "Bad practice." Generally speaking, a web application should be as stateless as conceivably possible. Even though, for example, you may need to know user information in order to authorize page viewing, that information could be saved on the client machine in the form of a cookie and the server simply validates the user information each and every time.

That would be ideal, but you can't always count on the client being able to save cookies. Furthermore, it involves validating the user in a stateless fashion, which potentially involves querying information from the database for a simple page request. Often times it's just simpler to save such information in the session.

However, once you've crossed the Rubicon, a lot of programmers are tempted to save not only authentication info in the session but many other things as well. This is an anti-pattern and tends to make your web application heavily dependent upon state, which is precisely what was supposed to be avoided in the first place.

Some programmers would hinge on technology like Spring (if you're using Java) to untangle what would otherwise be a mess of dependencies, but I would argue that that only makes it easier to create dependencies rather than eliminate them. Such technologies should aid your development, not make your anti-pattern less of a problem.

Therefore, a good rule of thumb is that if you can write it stateless, it is probably a better idea to do so or you risk to fall into this trap. Obviously you're going to run into situations in which this is required, but generally speaking, you should only save information that would otherwise be difficult to reacquire.

share|improve this answer
but you can't always count on the client being able to save cookies then AFAIK, you can't count on sessions, either. Aren't cookies used to identify which session belongs to which user, or are there other methods and that's simply the most common? –  Izkata Jun 20 '13 at 18:26
Session information is normally saved on the server for each server/client connection, and this became a popular trend for big web sites which couldn't rely on users having cookies enabled. There are options (and/or js libraries) which force the saving of said information on the client PC (which has been getting very popular as of late), but without HTML 5, cookies are the only way to achieve this. To my knowledge, there are no other ways of doing this. –  Neil Jun 25 '13 at 8:23
add comment

I think you're confusing two different topics: 1) sessions and 2) the page model of asp.net webforms

A web session is necessary for authentication a user. Ideally a session should only be used for this purpose. You shouldn't store user data in a session (whether it be on the server, in a cookie, or as asp.net/webforms does it: within the page itself). No one should say that a web session is bad, but rather, storing user data in a session is a bad practice. The reasons for not storing user data on the server include the same reasons to avoid global variables. Storing user data in cookies or in the page can introduce security issues. Using the page model of asp.net also doesn't adhere to the stateless nature of the web. You could do a search to find out more about why webforms is a bad design. Sessions on the other hand are a necessary part of web applications.

share|improve this answer
add comment

Controls and storing session state on a page are essentially a hack. Is the case of MS - a necessary one as they wanted to be able to provide a development environment where you could design pages as you can in winform environments.

MS have themselves moved towards the MVC architecture (latest version - MVC 4) which is more of a return to what the protocol actually should be - stateless.

There are situations where storing state is still handy but it should be understood that this is the exception rather than the rule.

share|improve this answer
add comment

Your Answer


