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
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.
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
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:
The XML mark up required to correctly encode the Whitebeam session ID in URLs
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
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
This method takes a URL as a parameter and modifies it to carry a the
Whitebeam session ID. See the method documentation
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
data is automatically available during subsequent page requests within the same
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.
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|
|1||Can store a large amount of data.||Limited storage.||Can store a large amount of data.|
|2||Limited 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.|
|3||Minimal 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.|
|4||Can work on all clients.||Unavailable to clients that have cookies disabled.||Works for all clients.|
|5||Data 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.|
|6||No client login required.||No client login required.||Requires client to login - and requires all pages to
- 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.
- For large amounts of data.
- Where the data is critical - or sensitive - e.g. passwords, credit
card numbers etc.
- 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.
- 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
- With self-registration unless the number of potential users is reasonable
- For transient or temporary data that is not critical e.g. last requested
- 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
- 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.