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.
More on regular expressions
- "Demystifying the syntax of regular expressions"
- "Regular expressions: Variations in support"
- "Unravel the mystery of sed and awk"
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:
with only the ASPSESSIONID part being consistent from session to session. The ASP.NET session ID looks like this:
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.
Figure A shows an Active Server Page that was written to test the MSC functions.
|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.
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.