What can you do with one cookie, a couple of stored procedures, and a random number? How about cooking up a medium-duty replacement for session variables? My recipe for tracking user Web sessions relies on the native speed of SQL stored procedures and the fault tolerance of a SQL Server database to deliver fast, reliable performance, and is device and platform independent in distributed processing environments.
An Alternative to Session Variables
Tracking users' Web sessions is necessary in all but the most basic Web-based scenarios.Web browser sessions are, by definition, temporary in nature. A Web session starts when the user opens a browser; when the browser is closed or the session times out from inactivity, the value assigned to the session variable is permanently lost. A user stranded in the middle of a Web transaction due to an interrupted or expired session is at best inconvenienced. At worst, having lost the carefully contemplated contents of his or her shopping cart, the customer simply clicks off the site, never to return.
Other factors can destroy session variables. Web sites in a distributed environment are prone to session variable loss when pages are distributed among servers for load balancing. The temporal nature of session variables isn't a new problem, and numerous alternatives have been developed to resolve it. However, many of the alternatives are language, platform, or device dependent, impose significant overhead, or have inherent security risks.
I offer an alternative to session variables that's independent of the language, platform or device being used and has low overhead. The only requirements for implementing this solution are a universally unique identifier (UUID), a user cookie, and a back-end SQL database. I use Active Server Pages (ASP) for demonstration purposes; however, you can adapt this code to any Web scripting language capable of processing user cookies and calling SQL stored procedures.
It's commonplace for Web developers to store session data in user cookies. But did you know that cookies from some of the largest and most popular Internet sites contain data that can be used to identify users and their personal information? In a Web application, security is job one.Any security analyst worth his or her salt will tell you that the best security is having nothing to hide. Because all Web sessions need to store a small amount of data that is, or could be, exposed to unauthorized users, the best option is to store the data securely. SQL Server does a good job of securing data within the database, but unless you establish some link from the user side to the user's secure data, you can't process user-level database transactions. The trick is to keep the user-side link as inscrutable as possible to prevent, or at least impede, those who would use it for less than noble purposes. If a cookie or other session data that uniquely identifies a user can be read by an unauthorized user, the whole purpose of secure data storage becomes moot.
A smarter approach is to use cookies to store information that only SQL can translate. Some developers choose a user ID to uniquely identify a user in a Web session. They might use a globally unique identifier (GUID) to generate user IDs and let themselves be comforted by the GUID's nonsequential nature. However, a hacker might still be able to use the cookie to impersonate the user on Web pages. Because the user ID is part of a permanent record, it doesn't expire, and using it in a cookie puts time on the hacker's side.
A 6-Step Recipe for Replacing Session Variables
Using a UUID cookie has two advantages over the user ID approach. First, the UUID isn't permanently tied to the database in any way. Second, the Web session expires on a predetermined schedule, and the UUID expires along with it, so you minimize the length of time during which the cookie can be put to unauthorized use and make it difficult to use cookies to access sensitive information.
My UUID cookie recipe has just a few simple ingredients:
- a SQL table to store session variables
- a UUID generator to generate the value that's stored in the user cookie
- stored procedures to add, update, and retrieve data
- an ASP or other script page to call the UUID generator and stored procedures
Cooking up a solution takes just six steps.
Step 1. Create the Sessvars table to store session variables. Table 1 shows the column names, data types, and data lengths for the SQL table.Add a column for each additional session variable you want to track. For example, you might add a shopping cart ID (for a retail site) or a project ID. Such ID values are typically primary keys that link to other tables. For efficiency and performance, store the smallest amount of data necessary. Don't store any information that identifies the user in the Sessvars table.
Step 2. Generate a UUID that will be used to identify the session and look up session data in the Sessvars table.A UUID is a 128-bit number that identifies a record, object, or entity that's unique and is expected to remain unique until approximately the year 3400. Servers can generate UUIDs, but you should use more than just a random-number algorithm to generate the UUID. To ensure a unique UUID, your generator should create it by using a combination of values. Common values to use in generating UUIDs are a time-stamp combined with the clock ID and node ID, preferably from an IEEE 802 MAC address. MAC addresses should be unique, although some manufacturers are known to reuse them. The generated UUID will be a 36-character alphanumeric string, such as d3179f30-5492-11da-8cd6-0800200c9a66. You can write your own custom UUID generator or use a third-party solution. If you use a third-party component to generate the UUID, you can use the ASP code similar to that in Listing 1.
Prev. page
[1]
2
next page 
