Client Session Tracking

Subject

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

• The problem to be solved.
• Whitebeam'sessions'
• Storing session identifiers in URLs
• How Presentation Pages access session data.
• Storing Information against a contact.
• Comparison of data storage options.
• Summary.

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 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.

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:

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 rb.page.session 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 rb.page.cookie 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.

Comparison

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.

Summary

Session Data

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.