I am looking for a new project to start on at home in my spare time, something that keeps me challenged and using new technologies (definitely AJAX, possibly even Ruby on Rails). Â The latest projects I have worked on setting up are background procedures for all of our personal computer data onto a network storage device. Â I then periodically swap out the hard drive in the device with a new one and store the hard drives in a fire proof safe.
Anyways, I want something a bit bigger, something that may take a while, but can have easily identifiable milestones to show progress. Â Any ideas would be helpful, I have tossed around the idea of starting a new E-commerce Project, one more surrounded by a different architecture than I used for cpCommerce, but just as modular.
Over the past year at work the projects I have been working on use Sessions to carry data from one page to the next. The data primarily stores the location in Persistent Storage where we are keeping the user’s data until they have finished their task. At this moment the problem does not exist but it will be an issue in the upcoming future.
The Issue:
Our problem is that if a user runs one of our web applications in two windows, the data will get mixed between the two sessions as the two windows share the same Session ID, as the Session ID is typically taken care of by the Browser.
In Internet Explorer, if you start two processes by running “iexplore.exe” each process will have a different Session ID, thus the issue does not exist. However, if you open one process and then do a File > New Window, the second Window reuses the first process and thus contains the same Session ID, or if your original window pops up a second window using JavaScript, the new Window will contain the same Session ID.
Likewise, if you have a Web Document shortcut on your desktop or in your Quick Launch bar that links to a particular website, the second, third, etc time you click on that shortcut it will reuse the first process of “iexplore.exe” and thus each subsequent click will use the same Session ID.
Firefox, Opera, etc no matter what steps you take to start them will always use the same Session ID. At least that is what my initial testing showed.
The Solutions:
There are two solutions I will talk about in this posting. The first deals with using a Unique Identifier in the Session Name, and the second deals with using Cookieless Sessions. Personally, I like the latter as it tends to require less coding changes.
Unique Identifier in the Session Name:
The first step would be to establish a unique identifier, most .NET users will understand the word GUID (Globally Unique IDentifier). Your session name would be something like “SessionName-<GUID>” or “SessionName-2345-234-2345-23456″. By doing this you have guaranteed a unique session for each instance of the application. After which you will have to pass the unique identifier to each corresponding page either by QueryString or a Hidden Form Field.
Hence the downside, each page will have to be able to read the value of the Hidden Form Field or QueryString, thus requiring several code changes to your existing applications.
Thus, I rate this change as a “Moderately Intensive” solution, as it will be tedious to change several pages in your existing applications to handle the Unique Identifier approach.
Cookieless Sessions:
Cookieless Sessions are extremely easy to do in .NET and only require a web.config change. Here is how it works.
When the user requests your application using an “absolute url”, a Unique Session ID is automatically generated for you and is placed in the URL of the browser like so “/applicationsFolder/(unique session id)/pagename”.
The problem is, once your application is started you will need to use relative urls to go to the next page, previous page, etc. Otherwise your application will generate a new Session ID and you will lose all data you have kept track of for the current user.
This includes pop-up windows that need to access the session data along with form action urls.
Along with the guarantee of a Unique Session ID, Cookieless Sessions are faster than Cookie Sessions (sessions handled by the browser). The main reason, is the browser no longer handles the Session Information to send it to your application. In short this means, the browser no longer has to read the session off your hard drive, setup the header information, and then send it to you on the Request for your application’s page, all because it is now embedded in the URL.
For these reasons, this is why Cookieless Sessions has my choice for best use when your application needs to be able to run multiple sessions for a single user.
In Summary:
Cookieless Sessions and using a Unique Identifier in the Session Name, can both solve the issue of running your application on two different sessions thus preventing data collision or data mix-match, however, they both share the same problem when it comes to bookmarking or copying and pasting a URL to someone else for help. Bookmarking and copying the URL will contains the Unique ID or the Session ID, thus the one major downside. However, if your application does not need to handle bookmarking or the copying and pasting of URLs, these solutions will be of great benefit.
Cookieless Sessions differ from regular sessions that are handled by the browser to send your application the Session ID in that the browser does not handle that aspect anymore, instead IIS with the help of .NET creates the Session ID in the URL and takes care of reading that ID for your application to use.
I hope this information finds itself useful to many others as I know it was well worth discovering for me.
Today a co-worker and myself had a “duh” moment. My co-worker was having a few problems with ‘parseInt(“000800″)’ returning a value of “0″, however, ‘parseInt(“800″)’ would return a value of “800″. This had me boggled too, as I always though “parseInt” operated in base10. As you can probably tell on where I am going with this, “parseInt” does not solely focus on base10, it can actually do any base (from 2 on up). When you do not supply the second optional parameter, it does its best to guess which base you may be referring to, and from the above results, the guessing could leave you in a state of mind boggling as it wasn’t the results you were expecting.
To solve the problem we simply change the code to ‘parseInt(“000800″, 10)’ and we got the result of “800″. Who knew “parseInt” had a second optional parameter? I was surprised.