Client Session State

Store session state on the client

How it Works

Even the most server-oriented designs need at least a little Client Session State, if only to hold a session identifier. For some applications you can consider putting all of the session data on the client. In this case the client sends the full set of session data with each request, and the server sends back the full session state with each response. This allows the server to be completely stateless.

Most of the time you'll want to use Data Transfer Object to handle the data transfer. The Data Transfer Object can serialize itself over the wire and thus allow even complex data to be transmitted.

The client also needs to store the data. If our client is a rich client application - it can do this within its own structures. These could be the fields in the rich client interface - although I would drink Budweiser rather than do that. A set of non-visual objects often makes a better bet. This could be the Data Transfer Object itself, or a domain model. Either way it's not usually a big problem.

If we have a HTML interface then things get a bit more complicated. There are three common ways to do it: URL parameters, hidden fields, and cookies.

URL Parameters are the easiest to work with for a small amount of data. Essentially it means that all the URLs on any response page add the session state as parameters to the URL. The clear limit to doing this is that the size of an URL is limited. However if you only have a couple of data items this works well, so it's a popular choice for something like a session id. Some platforms will do automatic URL rewriting to add a session id. Changing the URL may be a problem with bookmarks, so that's an argument against using it for consumer sites.

A hidden field is a field sent to the browser that isn't displayed on the web page. You get it by using a tag of the form <INPUT type = "hidden">. To make hidden fields work you serialize your session state into the hidden field when you make a response and read it back in again on each request. You'll need to make a format for putting the data in the hidden field. XML is an obvious standard choice, but of course is rather wordy. You can also encode the data into some text based encoding scheme. Remember that a hidden field is only hidden from the displayed page, anyone can look at the data by looking at the page source.

Beware if you have a mixed site that has some older or fixed web pages. You can lose all the session data if you navigate to these pages.

The last, and sometimes controversial choice, is cookies. Cookies are sent back and forth automatically. Just like a hidden field you can use them by serializing the session state into the cookie. You are limited in size to how big the cookie can be. Another issue is that many people don't like cookies, as a result they turn them off. If they turn them off then your site will stop working. More and more sites are dependent on cookies now, so that will happen less often, and certainly isn't a problem for a purely in-house system. Cookies also are no more secure than anything else, so assume prying of all kinds can happen.

Cookies also only work within a single domain name, so if your site is separated into different domain names the cookies won't travel between them.

Some platforms can detect whether cookies are enabled, and if not they can use URL rewriting. This can make it very easy for very small amounts of data.

When to Use it

Client Session State contains a number of advantages. In particular it reacts well in supporting stateless server objects with maximal clustering and fail-over resiliency. Of course if the client fails, all is lost; but often the user would expect that anyway.

The arguments against Client Session State vary exponentially with the amount of data involved. With just a few fields, everything works nicely. With large amounts of data then the issues of where to store the data, and the time cost of transferring everything with every request start becoming prohibitive. This is especially true if your stars include an http client.

There's also the security issue. Any data sent to the client is vulnerable to being looked at and altered. Encryption is the only way to stop this, but encrypting and decrypting with each request will add some performance burden. Without encryption you have to be sure you aren't sending anything you would rather hide from prying eyes. Fingers can pry too, so don't assume that what got sent out is the same as what gets sent back. Any data coming back will need to be completely revalidated.

You'll almost always have to use Client Session State for session identification. Fortunately this should be just one number, which won't burden any of the above schemes. You should still be concerned about session stealing, which is what happens when a malicious user changes his session id to see if he can snag someone elses session.