An ordinary web page is stateless - it doesn't have any way to tell what interactions you may have performed in the past. A stateless web page can tell whether the links in the page have been visited or not based on whether the page can be found in the browser cache but beyond that the page cannot tell anything about your past accesses.

At least that is how web pages work until such time as you introduce a mechanism for maintaining state between pages. There are two ways of maintaining state - one is to store something on your visitor's computer that can be read in by the browser on each visit (first/third party cookies or localStorage) and the other is to store the information inside the browser so that it only exists for the current browser session (session cookies or sessionStorage or in the querystring on the end of the web address).

The problem with these storage mechanisms is where you have more than one or two fields that need to be passed between the pages. Sometimes the amount of data to be passed can be quite large. Also some of these rely on JavaScript and so don't work when JavaScript is disabled. This is where sessions come in. What sessions do is to move the storage of the data from the browser to the server. Instead of storing of the information is a cookie or querystring, sessions simply pass a session id between the pages (either using a session cookie or the querystring) and use that to identify which set of data stored on the server belong to this particular visitor. The session data still gets passed back and forth but in different headers where they can't be manipulated from JavaScript - and hence making the data more secure. It also makes it easy to go one step further and store the actual session data in a database on the server where the individual fields required by pages can be retrieved for those pages and just pass enough data via the session to identify which visitor it is.

One thing that you can do with sessions is to link pages together where information your visitor enters on one page is available to other pages on the site - for example if you have several forms they can fill out you can use a session to prefill the fields on each form that have already been entered on prior forms.

A more obvious use for sessions is where you require your visitors to login to use your site. In this case the session is used to pass information about which particular login id is being used and also to identify whether your visitor has logged in or not. In this situation moving most of the data out of the session into a database makes even more sense since you will almost certainly want it to be available again the next time that person logs in.

Sessions provide a mechanism for giving web pages a state based on prior actions within the browser without needing to pass huge amounts of information via other mechanisms that were never intended to hold much information. Sessions also make it harder to predict what value other current users may be using as it generates a random value to identify each session rather than relying on specific known data. If identifiable data were used to pass the state between pages then anyone who knew that data could potentially intercept the session by sending the same data to the server.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow