We @ Vanguard Software Group and also many other places we came across situations where we needed to somehow uniquely identify the browser instance of the user working with asp.net site (the concept applies to any web technology – asp, php, cold fusion …).
1- Session behaviour when you are working with In Process & with State Server. In earlier mode the application events for session end and start work fine, but still not when user closes the browser.
2- In case of State Server mode the session application events done even get fired, so we are at loss to how to track somebody who is no longer using our site.
The solution is simple one, to get RID of the session default implementation all-together :)… May of you will be surprised to hear it. But anyways,
Here is the idea (which we actually implemented in full blown manner)
When you’re working with web applications, your applications do have a start page. That start page can be used to generate a unique token for that particualr instance of the browser, and with each request to following append that token to Query strings for any more pages you visit while getting your user navigate through different areas of the websites.
When user requests your site http://www.yoursite.com, it goes to default.aspx (or whatever default you set) – Now generate GUID and store it within the ViewState of the page.
Now when user logs in – just pass that stored GUID to next page as Parameter. it will be something like http://www.yoursite.com/Welcome.aspx?Guid=%5BGenerated GUID here]
Now, at this point that “Guid” is the unique token that you need to have for storing any information that you need for that logged in user.
Now, you will be thinking if we are not using session than where to store this information?
There can be more than one ways you could do that:
1- Use Cache
2- Use Distributed Cache (for Webfarm/ webgarden deployments)
For first option of “Cache”, just put in the Guid prefix with each key you put in, just like
Cache.Add( Request[“”Guid] + “Key”, “Value”)
Now, above is pretty straight forward – you can enhance it more to work wonders for you. Another you could do that, you can add timespan for the cached object so it does not lives in there for application life cycle or whatever default value is.
For Second option for Distributed cache you can use following
2- Microsoft Project named “Velocity”
Being Microsoft guy, I would like to use Velocity which is growing quite rapidly and quite fast as well. You search google.com for “Velocity” and you will find bundle of articles on how to use it.
But to use this option – beware that you need to measure your project size and deployment strategy, as it requires Power Shell commands to work it out.
Generate Unique token for first request from a user to your application, and use that token until user logs off or closes the browser. When user opens new one that GUID gets created again, and there is no way that two brwoser instances would share that same guid. if you go this path options are unlimited. You apply this thought on cookie names etc …