Should session variables be avoided?

Question

I used to heavily rely on session variables in the past, but have recently found many of them to be unnecessary, using things like query string parameters instead.

A colleague of mine refuses to use session variables. Is this a realistic goal and should session variables be avoided for any practical reasons? Can session variables be avoided completely (except for session cookies to allow logins) and would this result in better designs?

Some of the reasons my colleague has for not using them:

• Untyped nature of session variables
• Session time-outs causing loss of state
• Global scope nature of session variables
• Load balancing servers losing sessions (.Net specific?)
• Application pools/servers restarting
• They are unnecessary

Answer 1

If you have a session variable in your application, ask yourself this:

When I click the back button of my browser, what value do I want my variable to have?

If the answer is "the current value", session variables may be useful. An example would be a shopping cart: you don't expect things to be removed from the shopping cart as you go back through the history. It's always in its current state.

If the answer is "a previous value", you should not be using session variables. Bad uses I have seen include passing a parameter between pages. If I click the back button to get back to a page, the page does not necessarily get the correct parameter. Also, if I open two tabs, how is my site going to behave then?

Getting the back button behaviour right is by no means the be-all-and-end-all, but it helps you think about a web site as a stateless application. In general, I find appropriate uses of session variables to be few and far between.

Answer 2

The HTTP protocol is stateless. Sessions are a way to preserve client state across HTTP requests. You may choose to do that with a platform's built-in session handling or do it yourself with query string parameters. Either way some concept of a session is necessary for many tasks.

Your colleague probably dislikes a specific implementation, or hasn't been using sessions for their intended purposes. If you need to retain information about a specific client connection across HTTP requests, you need some form of session persistence.

The following issues are implementation specific:

Untyped nature of session variables

Global scope nature of session variables

Load balancing servers losing sessions

Application pools/servers restarting

For example, I most often work in PHP and store my session information in a relational database. So my session variables are typed. Load balancing and server restarts don't cause any session issues.

This one is more interesting:

Session time-outs causing loss of state

Sessions are most often preserved via cookies. These can be deleted by the client at any time. But they can also be preserved via a query string parameter and therefore never time out on the client. The server timeout is up to you. So even this issue is implementation specific.

Let's not throw out the entire concept of sessions just because we don't like a particular implementation. Any good web application framework will facilitate using sessions properly to preserve user logins or retain anything else specific to the user's current visit. A user's database record can (and should) be used to store things specific to them when logged in. Anonymous visitors, however, may have temporary information also worth preserving in their session, such as a short list of recent pages visited or the preference to hide a notice they've already seen. Generally only smaller temporary information is appropriate for session storage.

Answer 3

Others have made a lot of good points (which I will avoid repeating), but there is one aspect of your buddy's technique that has not been discussed yet: security.

Its impossible to know what kind of vulnerabilities you open up without looking at the code, but here's a few things I can think of off the top of my head.

• Session fixation: A powerful attack that is slightly easier if you can just have the user click a link that already has the necessary info in the URL (rather than trying to get the user to use a machine that has its cookies appropriately set).
• SQL injection (or other malicious input): Never trust anything that comes from the user. Session variables have an advantage of never leaving the server, thus the user cannot directly change them. While you should sanitize data before putting it into the session, you can always trust the values you get out afterwards. If everything is passed around through the query string, you have a LOT of validating you need to do to make sure that you're not accepting malicious input.
• Corrupting data by using falsified inputs: Similar to SQL injection, how much data are you passing back and forth? How crucial is it? Can I change the behavior of your app by changing a value in the query string? Can I corrupt the data on your server by changing values? If I manage to corrupt the data on the server, will it affect other users? (If your answer was "no", my response is "are you sure? You have a lot of places you need to check.").

All of these can still happen when you use Sessions, but they can get a lot easier if your buddy doesn't know what he's doing.

Answer 4

Session variables are like the old Basic global variables to some degree. The burden is on the user to keep track of them, what's in them, their scope and how they are used; just like in old versions of BASIC. That being said, why would someone totally discount the use of a mechanism that is obviously designed to be an integral and very importaint part of the programming model (ASP, MVC etc.)?

The only bad thing that I've run into in using Session variables is that it puts the burden on you to keep track of them, make sure they are populated with relavent data and disposing of them.

Isn't that what we do when we are programming any way?

Answer 5

I used to think like your colleague due to some bad experiences I'd had debugging issues related to session variables, which were really just incompetence on my part. Yes you can get by to some extent without session variables, using query strings, hidden fields in forms and other things. However it very quickly gets cumbersome to do it this way if your application has anything beyond the most basic logic flow to determine state. There's also the security risk of showing the inner workings of your application via query strings and hidden fields, any of which can serve as attack vectors.

When working with session variables you just need to keep track of when they get set and unset, as this will determine the logic flow of the application. It's like memory management in a language like C.

Note that this is just from my experience working with PHP on a relatively small project with no frameworks, things may be different on other platforms but I think the general principle still applies.

Answer 6

As previously stated HTTP is Stateless and Session Variable break that. HTTP design to be stateless helps caching of resources. For resources that are publicly available.

It's possible to design a website without session variable but it's harder. The hardest (IMHO) is the fancy login/logout, HTTP authentication schemes does not provide the tools needed to authenticate via an HTML form (you might hack something with javascript - XHR to https://untel:[email protected]) and it's even harder to logout and be cross browser compatible. there was some discussion the w3 mailling lists about that but if I remember correctly the idea was dropped.

For the rest, you should be able to live without Session variables. You will have some state on a database, files or anywhere but the use for Session variables should be rare.

If your user have a shopping cart, it's a variable session only if the user is supposed to be able to browse on two computer/browser without sharing the cart.