ASP provides a single session ID per client, which is a potential problem when the time comes to unify existing extranet or intranet applications under a single logon. There is a very real possibility that these often independently developed applications use some of the same session variable names. The reasons for duplication of names range from “borrowing” code to the name being a common descriptor, like total. Regardless of the reason, this duplication of variable names is a problem waiting to happen when multiple applications are concurrently open from the same browser occurrence.
Did you miss it?
For more information on the issues surrounding the use of session IDs in both "classic" ASP and ASP.NET, see my previous article, "Maintaining session state in ASP."
For instance, imagine a sales-forecasting application overlaying the total of an order being placed. While Star Trek: First Contact was a great movie, I’m pretty sure that I don’t want to pay $23.4 million for the DVD. I’m also pretty sure that anyone being charged $23.4 million would be scared away for good. An error like this hitting production is usually enough to cause a bout of resume updating among the developers.
The traditional way of dealing with this type of problem is a rewrite of the individual applications to resolve the session variable conflicts. The problem with this approach is that, until recently, Web developers were a rather mobile group. Developers often left to “pursue other opportunities,” leaving in their wake a lack of knowledge about the applications they created. As a result, major changes weren’t a very good idea.
After some thought, I realized that the easiest way to avoid having major code changes was to force ASP to give each application its own session ID. Instead of major changes, there would be only minor changes to the applications. These changes would basically give each application its own session ID when it was first selected on the main menu, and that session ID would be used until the application either closed or timed out. I was excited by this idea. It was elegant, it was sexy, and I had no idea how to make it work.
How to get a new session ID
When the test page first appeared in the browser, the session ID 300669498 was displayed. But after a refresh, the session ID changed to 300669499. It worked! My feeling of omnipotence lasted for nearly a full minute before I remembered that the first session ID was gone. It was as if the client were a first-time visitor. All that I had accomplished was coding a client-side equivalent to the server-side Session.Abandon. Well, at least I could get a new session ID.
The multiple session ID cookie
Maintaining multiple session IDs is more than a matter of blowing away the encrypted session ID cookie. A way to get, store, and restore multiple session IDs is needed. The more I thought about the problem of how to retrieve the prior session IDs, the more I kept thinking of cookies. Although it seemed kind of schizophrenic to store a cookie in a cookie, the idea of having more than one session ID is schizophrenic, too. In fact, it would probably be best to store as many session ID cookies as possible in a single cookie. This would leave 18 cookies remaining for other purposes after ASP and the multiple session ID cookie each used one cookie.
Because I didn’t want to write throwaway code, the multiple session ID cookie (MSC) needed to be able to store both the classic ASP and the ASP.NET encrypted session ID cookies. Handling both classic ASP and ASP.NET would increase the flexibility of the MSC. I decided that the MSC would have the format shown in Table A.
Storing and restoring the current session ID
After determining the format of the MSC, I needed to break down the multiple session management into logical pieces. The first step was a function to destroy the current encrypted session ID cookie, which was coded during my previous bout of megalomania. Other pieces of the puzzle were to locate a previously stored encrypted session ID cookie in the MSC, store the current encrypted session ID cookie in the MSC, restore a previously stored encrypted session ID cookie from the MSC, and replace an encrypted session ID cookie in the MSC.
Several other hurdles must be crossed before multiple sessions can be managed. Cookies must be created, modified, retrieved, and destroyed, but these can be handled using tools that most developers have written or acquired over the years. The remaining challenge involves determining whether the page is classic ASP or ASP.NET, which can be accomplished on the client side by checking the document object’s URL property for “.aspx.”
The purpose of this technique is to provide an alternative to rewriting existing applications so that they can play together nicely without corrupting common session variables. In my next ASP session management article, I will explain how the individual MSC client-side functions work and show you an example of the results.
Hand in the cookie jar
How do you manage multiple sessions in ASP? Tell us about your experience or post a comment below.