Developer

Use JavaScript to implement multiple session ID cookies

Get a little more mileage out of ASP by using JavaScript to implement multiple session ID cookies. We'll give you the basic functions and some sample code so you can give it a try.


In "Making multiple session IDs work in ASP," I introduced the concept of the multiple session ID cookie (MSC). Now it's time to consider the gory details of how the JavaScript functions implement it.

The foundation client-side functions
When I was a kid my father worked construction, and during the summer, I would hang out on residential construction jobs, occasionally acting as a gofer. Through osmosis, I picked up several of the concepts of construction. Some of these ideas can be applied to the programming process—most especially, the idea that all construction relies on a good foundation. This is as true for applications as it is for houses. If the foundation is weak, the structure is going to collapse.

Because the MSC is cookie based, the JavaScript cookie functions are the first layer of the foundation. These functions set a cookie to a particular value, get the value of an existing cookie, and delete an existing cookie—hence their names: setCookie, getCookie, and deleteCookie. These functions are pretty much the same as the standard JavaScript cookie functions that everyone writes sooner or later to handle the mundane task of working with cookies, with one exception: the getCookie function uses regular expressions. If you’re not familiar with regular expressions, I recommend reading the Builder.Com articles listed below.

More on regular expressions


The second layer of the foundation is a binary search function that is used by higher functions to search the MSC for a particular session ID. For those who napped during computer science class, a binary search is a method of searching a sorted array. Because the array is sorted, it isn’t necessary to check every element one after another until a match is found. Instead, the array is divided in half and the middle element is tested. If it is larger than the search key, the process is repeated using the first half of the array; if it is smaller, the second half of the array is searched. This process is repeated until a match is found or it has been determined that a match does not exist. If a match is found, the index of the matching element is returned to the caller; otherwise, -1 is returned.

The third layer of the foundation is a utility function whose purpose is to find a particular session ID in the MSC and return it to the caller. The function findSession splits the MSC into individual session IDs that are further split to isolate the subsystem IDs. These subsystem IDs are then passed to binarySearch, which returns a value to the caller.

The fourth layer of the foundation is the function dotNet, which is used to determine whether the current page is classic ASP or ASP.NET. This makes a difference in determining the format of the session ID cookie and therefore knowing what to look for. In classic ASP, the session ID looks something like this:
ASPSESSIONIDGQQGQGCS=JHMBOBKCBINEHLPKJHOPABBE

with only the ASPSESSIONID part being consistent from session to session. The ASP.NET session ID looks like this:
asp.net_sessionid=jhmbobkcbinehlpkjhopabbe

with only the cookie value being variable.

The final layer of the foundation is the function destroySession. It destroys the current session ID cookie, fooling ASP into giving the client a new session ID. This is accomplished by searching the document.cookie collection looking for the type of session ID cookie that dotNet indicates. Once the cookie name is found, it’s passed to deleteCookie, which blows it away.

The MSC client-side functions
Now that the foundation has been laid, we can move on to the structure itself, which consists of four functions. These functions handle the higher-level tasks of storing the current session ID, replacing a previously stored session ID with the current session ID, and restoring a prior session ID.

As the name suggests, the function storeSession stores the current session ID in the MSC. First, the current session ID is located in the same manner as destroySession. It is then formatted to conform to the MSC format and put in an array with the other stored session IDs. This array is sorted and joined to form the full MSC. The function replaceSession works identically to storeSession with one exception: replaceSession can overlay a previously stored session ID, while storeSession cannot.

To continue my building analogy, the final part of the structure is restoreSession, which finds a previously stored session ID in the MSC and overlays the current session ID with the stored session ID. As far as ASP is concerned, the client’s browser is now a prior client.

An example
Figure A shows an Active Server Page that was written to test the MSC functions.

Figure A
ASP page to test MSC functions


The page SessionTest4.asp shows five columns of three rows of buttons. The first four columns are used to invoke the MSC functions indicated by the button’s labels. Each of the columns corresponds to an MSC subsystem ID from “ses1” through “ses4.” The fifth column of buttons does exactly what their labels say. Create New Session starts a new session ID by invoking the function destroySession. Reload Page will force a reload of this page, and Clear Session clears the MSC.

You can download the code here and play with the example, which contains all of the functions required to manage multiple ASP session IDs. When integrating these functions into an existing system, store the current session ID cookie using the page’s onload event handler and restore a session ID using the page’s onbeforeunload event handler.

Conclusion
Managing multiple session IDs in ASP began as a way to solve a particular problem I encountered while developing a B2B e-commerce site. However, as time progressed, it became a reason to learn more about how ASP managed sessions and how to coerce ASP into doing just a little more than it was designed to do.

 

Editor's Picks