Client Session Tracking

Site Map
Application Guide
  Quick Start
  PHP and ASP
  Writing Apps
    Postgres Interface
    XML Processing
    Using XPath
    Binary Object
    Using HttpRequest
    Meta Data
    Memb Services
    Page Look&feel
    Message Groups
    Form Handling
Contact Whitebeam
Whitebeam Users

Client Session Tracking


This Tutorial concentrates on the issue of storing and retrieving state information associated with a user session. The following topics are covered:

Overview of Session Data

The Internet is implemented using a loose collection of co-operating standards. These standards have evolved over time, and over time more facilities have been bolted onto the original core technology. Some of these subsequent developments have been hampered by deficiencies in the underlying technology.

One of the main problems to plague web designers is that of tracking a users 'session', particularly with a view to storing and retrieving information about the users progress through the application or site, their preferences and the such like.

Unfortunately the core Internet technologies are 'stateless' - no information is carried between an initial request for a page and requests for subsequent pages. There is no concept of a session, no start of session and no end of session. The Internet technology solution to this uses something called a cookie, which is a small piece of data loaded onto the clients machine as part of a web response. These cookies can only store a small amount of server defined information and the browser will present that information back to the server in subsequent page requests to the same site.

This can work fairly well - but there is an uneasy feeling among many people about the placement of cookies on their machines and a number of individuals and a number of corporations disable cookies on their machines.

Alternatives exist - all of which are messy.

Whitebeam Sessions

The Whitebeam system attempts to abstract away some of the complexity of session tracking from the web designer. The system identifies new 'sessions' and allocates them a WhitebeamSession ID. This ID will be placed in a cookie sent to the browser. In the case where the browser has cookies disabled the Whitebeam system will attempt - with a little help from the author - to mark URLs that reference the same site with the session ID.

The Whitebeam system will attempt to extract the ID firstly from a client provided cookie and failing that, by checking the URL provided by the client. Extracting the ID is entirely hidden from the author.

On the server side the Whitebeam Object Model provides the means of storing complex session data against that ID and recovering the data when the next session request is received. This data can be fairly large and is stored within the Whitebeam environment. This has the advantage the it does not consume network bandwidth with the client.

Note that this is intended to track user sessions. Because there is no session concept built into the underlying Web technologies the Whitebeam system has no means to determine the start or end of a session.

A session starts the first time the Presentation Engine receives a request for a page and that request does not contain valid session identification.

A session terminates when the Presentation Engine fails to receive any page requests for a certain period of time. The exact value of this time is variable but at a minimum is a half hour.

The interface with the session tracking data has the following aspects:

  1. The XML mark up required to correctly encode the Whitebeam session ID in URLs

  2. The JavaScript interface to store and retrieve information against that session.

URL Modification

The easiest way of getting a client to store and return the session ID on behalf of an application is through use of client side cookie. You can write a site that only works with clients that have cookies enabled. There are many sites that take this approach - and they work pretty well with a consumer based target audience.

In some quarters the ability of a remote, unauthorised entity being able to place information on a client is considered a security threat and for this reason all mainstream browsers allow the storage of cookies to be disabled. In these environments tracking session is more complicated and requires a little more effort on behalf of the web author.

In these environments the session ID can be passed to the client buried within all URLs that reference pages on the same site (or more correctly, on the set of pages across which a session has to be tracked). To make this easy the Whitebeam system provides some mechanisms to do this for you. There are two facilities available:


This is an XML attribute that can be used on any XML, HTML or XHTML tag that includes a 'src' or 'href' attributes. The behaviour of the attribute is to search the other attributes in the tag for occurrences of either 'src' or 'href', If these attributes exist then the URL contained within them is modified to carry the Whitebeam session ID. The attribute can also be used in <form...> tags, with a similar effect - the form this time is modified to have a hidden parameter to carry the session ID.

This method takes a URL as a parameter and modifies it to carry a the Whitebeam session ID. See the method documentation for details.

Storing and Retrieving Session Data

Its one thing to be able to identify a client session - but this facility alone has limited usefulness. Generally an application needs to store information against that session and make use of that information on various pages of a site. For example, consider a page containing a search request. If an end-user completes a search form then next time he visits the form, within the same session, the field values are initialised with the values entered previously.

The Whitebeam System facilitates the storage of such short term 'session' data on the server using the the object. This object allows the author to store arbitrary data against the session using the WhitebeamMetadata model. Simply put - the author can store and arbitrary JavaScript structure against a session. That data is automatically available during subsequent page requests within the same session.

Alternatives to storing the data on the server side is to use client side storage. This reduces the storage overhead at the server end - but has a number implications that may make it difficult to implement a nontrivial project using client side storage. For those applications that are happy to store information on the client side the Whitebeam system provides the object. The interface is very similar to server side storage.

Storing Information against Contact

The alternative to storing data against a session is to store it against a 'contact'. There are lots of advantages to this - as well as a few disadvantages. Basically the disadvantage is that it requires you to have a user account for each visitor - and have those visitors 'log-in' each time they visit the site.

The contact template provides a metadata field against each contact where the required data can be stored.


So there are at least three mechanisms - and places - to store session-like data. The following summarises the differences between them to help the web designer choose the most appropriate for a specific application.

Server Side (Whitebeam Session)Client Side (Cookies)In Contacts Template
1Can store a large amount of data.Limited storage.Can store a large amount of data.
2Limited period - session automatically destroyed after a period of inactivity.Data may be stored for a significant period of time - and may persist indefinitely - useful for storing preferences.Data may be stored indefinitely but server data size can grow rapidly - and is not automatically discarded.
3Minimal increase in network traffic.All data is sent back and forth between the client and the server - potentially a large increase in traffic.No increase in network traffic.
4Can work on all clients.Unavailable to clients that have cookies disabled.Works for all clients.
5Data held securely on Whitebeam System.Insecure storage on client. Passed as 'clear-text' across the network and accessible by anyone.Data held securely on Whitebeam System.
6No client login required.No client login required.Requires client to login - and requires all pages to use authentication.


Session Data

  • Data is small
  • Don't mind requiring cookies to be enabled on the client.
  • Ideal for storing temporary form values.
  • Ideal for application preferences when a login is not required.
  • In 'public' sites with self registration where the potential number of registrants is unbounded.
Don't Use
  • For large amounts of data.
  • Where the data is critical - or sensitive - e.g. passwords, credit card numbers etc.
Session DataUse
  • Data is large.
  • Want to work with all clients - even those with cookies disabled.
  • Ideal for storing temporary form values.
  • To store transient or temporary data that is not critical e.g. last requested search string.
Don't Use
  • Data needs to be permanent.
  • For data that is specific to an individual rather than a session.
  • For permanent data - e.g. customisation parameters.
  • To store sensitive data such as credit card numbers
Don't Use
  • With self-registration unless the number of potential users is reasonable bounded.
  • For transient or temporary data that is not critical e.g. last requested search string.
  • Where you don't want people to have to log into the application.
  • For storing temporary form values.

You should be able to see from the table above that each of these techniques have different uses. It is not unusual for an application to use two, or even all three alternatives:

  • Session Data stores temporary form data, last search request.
  • Cookie stores preferences in sites that don't have registered users.
  • Contact stores information for registered users, along with more sophisticated application preferences such as interest subjects.
Whitebeam release 1.3.36
(loadtime : 8ms)