A Recipe for Replacing Session Variables

Step 3. Write the UUID to a user cookie. Although the UUID is stored in a relatively insecure location outside the database, it doesn't contain any information that would identify the user.The following code writes the UUID to a user cookie and sets an expiration date for the cookie only if the user doesn't have a valid, unexpired cookie from a prior session:

Response.Cookies("SessCookie")= 
     strGuid 
Response.Cookies("SessCookie") 
     .Expires = Date + 1 

For additional cookie security, specify both the domain and path when storing the cookie:

Response.Cookies("SessCookie") 
    .domain = your-domain.com 
Response.Cookies("SessCookie") 
    .path = "/virtual/secure" 

where your-domain.com is the name of the domain that will store the cookie and / virtual/secure is the path to the storage location.

Step 4. Add the session cookie record to the Sessvars table. Listing 2 shows ASP code that calls a stored procedure to add the UUID to the Sessvars table. You'll need to use the connection method appropriate for your environment. You can download the code for the stored procedure at InstantDoc ID 49114.Always use a stored procedure to add even a single record to a table. Stored procedures are precompiled and more secure than dynamic SQL.

Step 5. Read the session cookie on every server page and add, update, or retrieve values from the Sessvars table as necessary. Listing 3 shows the code for reading and sending the cookie data to the stored procedure. At first blush, reading every server page might seem burdensome, but the overhead is low compared with storing session data in memory variables on the Web server. Besides, session variables have a tendency to disappear and are fairly heavy users of server resources. Making the SQL database do the work in the form of precompiled stored procedures frees up Web server resources and is generally more efficient.To improve performance when adding or updating data in your Sessvars table, use a data retrieval method such as GetRows, as the code in Listing 3 does. Using GetRows places record-set data in an array, letting you close the SQL connection immediately.

Step 6. Finally, run an automated SQL job that deletes session data every 24 hours or on a specified schedule.

When you follow this recipe, the Web session will expire only when you want it to, even in clustered or nonheterogeneous environments. If users close the browser and reopen it later,their session data remains intact until the UUID cookie expires or you delete the session data in the SQL database. By keeping the session alive in this manner, you can ensure that otherwise volatile data, such as shopping carts or data searches, persists.

Caveats for Using Cookies
Storing session data in a SQL database and retrieving it with a user cookie has advantages and disadvantages.The main advantage is that you can easily make session data persist without using volatile, resource-intensive memory variables. One disadvantage is that you know only what the user is doing but not who he or she is.And if a different user subsequently visits your site from the same machine, the new user will have the same access as the earlier user on that machine until the session expires.

From a security standpoint, the UUID cookie method shouldn't be considered secure on public Web sites that don't require a login. On a secure intranet or extranet, where users are required to log in, you can still use the cookie-to-SQL session manager, and you'll know who the user is from the context of a secure login.

If your Web site requires users to log in and be validated, you can increase Web page security by storing a second UUID in another user cookie. Link the second UUID to the real user ID in the SQL database behind the scenes using a simple translation table, and expire the second UUID on a regular basis. If someone happens to read the cookies from the user's computer or capture packets from your site, the intruder will see only meaningless, nonsequential numbers. By the time a malicious user discovers the cookie and tries to use it to retrieve data, the cookie likely will have expired and be useless. If your UUIDs conform to published specifications and each one is truly unique and universal, they also foil the game of "guess the next ID" because it's impossible to use one UUID to guess or mathematically derive another UUID. See Related Reading for a list of resources about specifications.

Other Basic Assumptions
The UUID cookie method assumes the user allows cookies. Users who turn them off quickly discover they can't conduct much useful business on the public information highway.You can always check for disabled cookies and redirect the user to another page as appropriate.

The UUID cookie approach also assumes that just one instance of your application is running, because switching between multiple browser sessions using the same cookie doesn't work. The other assumptions are that you've hardened your SQL box, secured it properly behind your demilitarized zone (DMZ), and are using stored procedures instead of dynamic SQL.

This approach for tracking user sessions lets you manage Web sessions on a variety of platforms using any SQL database that supports stored procedures. It also overcomes some of the problems inherent in using session variables. All the ingredients you need to implement this method should be readily available regardless of the environment you're working in.