Statelessness Sophistication

We can address several of the main flaws in cookies by moving the burden of state to the server rather than the client. In this way, a server will be configured to 'remember' the personalization data for each user. In doing so, we can achieve portability and reduce fear, since data is not being 'tagged' on the visitor's own machine.

Commonly, databases are used at the back-end to store personalization settings for each user. The database-backed solution to state has become very common on the Internet, and as such, so have some one of its major weaknesses:

The server needs a way to identify the user, so it knows whose records to pull from the database. Typically sites request a login name and password for this purpose. But with so many sites asking for this type of information -- with different constraints on the syntax of valid login names and passwords -- it's nearly impossible for users to remember their own login information. Sites are then saddled with needing to build 'reminder' systems on the back-end to help out people who have inevitably forgotten.

Because the collection of user data is centralized, it is more vulnerable to loss, corruption, or malice. Robust back-up procedures are needed lest a single incident wipe out the personalization settings for hundreds or thousands of users. Decisions must be made about what types of information are too sensitive to store in such a centralized manner -- a number of high profile cases have hit the media wherein theives have made off with mass piles of credit card accounts stolen from weakly secured, centralized back-end databases.

By and large, using databases to store the majority of personalization settings is a good idea. We'll look more closely at this technique in the next installment of this series. Still, cookies have their place, and are not rendered entirely obsolete in the face of server-side statefulness.

Living Together in Harmony

You've probably visited web sites which rely on a login to access personalization data. Some of these sites also offer a "login-less" access method -- a link or button that invites, "Click here if you want us to remember your login." The lure is that you won't have to manually enter your name and password everytime you visit. The technique used, of course, is cookies.

More specifically, a hybrid solution of cookies and back-end databases. The back-end database contains the personalization data, keyed to a login name and password. The cookie, on the user's own machine, contains the login name and password. Here we get the best of both worlds: the convenience of cookies lets the visitor enter the personalized site without manually logging in; but the user without access to the cookie, either by choice or location, has the option to manually login to their personalized settings.

Cookies may offer a second convenience as well. We've talked about state and how it relates to multiple sessions -- that is, visits to a web site over time. Within a session, though, a visitor may access several different pages inside your web site. Each page may need to know the user's personalization settings, without requiring the user to login for every page on the site.

Some sites will 'remember' a user throughout a visit session using server-side techniques, such as the database or special "stateful" modules programmed into application serving software. An alternative, though, is to issue a session-long cookie. That is, a temporary cookie containg the personalization data pulled from the server-side database. This technique allows rapid, convenient access to the personalization data throughout the browsing session, but the cookie does not remain on the user's machine after the browsing session is complete. Session-long cookies are simply cookies with no expiration date specified, as we'll see later.

Reinventing the wheel
The Perl You Need to Know
In the Kitchen with Perl