How to handle multiple sessions for same website using same browser with different tabs. ASP.net C#

Well, as noted, session() is global to the user. In fact, they can launch two different browsers, say FireFox, and Edge – and they will BOTH continue to use the same session values!

What this REALLY means is that from day one, your designs HAVE to make this assumption. If you don’t make this simple assumption, then you can be in for a world of BIG hurt if you "just out of the blue" wrote code without the above concept in mind.

In other words, for global things, then session() is fine. However, if you start writing BOATLOADS of code based on using session() to persist values on a SINGLE page? DON’T!!!

And it takes a few seconds in 99% of cases to flip code from session[] to ViewState[] for a given page.

So, now then the ONLY issue is when we use session[] to pass values around from page to page.

Using session() for passing values is ok, but NOT for such information like PK row values such as booking a hotel room, or say selecting a house to buy.

However, like a lot of people, the problem is we don’t really think about this issue, or don’t know about this issue until it is too late.

So, this is a problem. You want the "easy" of session(), but we need a way to pass around values from page to page.

As noted, one way is to pass values around using parameters in the URL. But then again, that’s rather ugly. Sure, for some things like to filter a grid by a given city, then that can be really nice, since then users can save such a URL, or often modify the URL to their liking.

However, for a simple pick of a house or say a hotel room to book, then you can’t of course allow or risk doing that (since you would be exposing primary row keys and selection in plain view. Worse yet, it can be a huge security risk. (some very early credit card and other types of sites would actually let you type in values that would let you get and see OTHER USERS information!!!

So, here is how you can handle this issue:

First up, we have these simple choices:

Parameters in URL - they are ugly, high risk, but GREAT for things like city filters etc.

Session() - this is global to the user - includes separate browsers launched.

ViewState - this is per web page - ideal for what we need, and PER PAGE!!!

HiddenFields (in markup) - again, per page - ideal for what we need, but PER PAGE!!!

So, in regards the per page options, only URL parameters can work for passing.
(sans the session() option).

ViewState is great for per page, but you can’t use ViewState for passing values between pages. Keep in mind that viewstate is client side, and while encrypted?

Well, for not super high security, then it ok to use. Just remember, ViewState should be kept small, since it goes with EACH button click and PostBack, ViewState becomes part of that "package" and post.

ViewState is part of the page post-back. This is certainly ok, and even better then hidden fields which appear in plain view client side. Just keep in mind ViewState increases the size of each and every post back for a page. So, keep it light, small, and don’t persist LARGE amounts of data like say some large dataset.
(unlike Session() which is 100% server side).

So, we need:
Easy approach – per page, but NOT have to re-write a lot of code.

So, while you could say munge up the URL, then they start to look really ugly, and while that might get you a session for the given page, your session() code has to be changed – and it gets messy.

so, just limit using session() to pass values, but NOT persist per page – and you then quite much home free.

In effect? I am saying NEVER use Session to persist values in a page unless you have no other reasonable choice. (use ViewState).

The other issue? What good is to suggest some approach in which you have to re-write a boatload of existing code?

I find that even a page with quite a bit of Session() stuff can in less then a minute be changed over to use ViewState. In fact, you can in most cases use search + replace Session to Viewstate.

So, the only issue left is now the passing of values from page to page.

Use session freely to pass values to the next page. However, for any values that are say PK values, or row identification values, or values that will "break" or "damage" the operations of that page if MORE then one page were to be open? Then simple transfer the values in session to next page AND THEN ALWAYS on FIRST PAGE load (IsPostBack = false), you simple transfer the values to ViewState.

This works really nice, and is BOATLOADS of less work then trying to adopt some silly parameter in the URL or what ever other junk people propose. In other words, we want the LEAST DAMAGE to existing code.

And also, because session() is global? Then it starts to get REALLY messy. I want to say pass 4 values to the next page. And then on that page I might have some more values – all of sudden, while writing code, you can’t even remember what session() name to use – and it piles up into a BIG MESS REALLY fast. You wind up with a boatload of session values – ever more growing in your application. It just a mess, and global values tend to be a HUGE mess in any applcation – including that of using session().

And, often, 4-5 values are for the SPECIFIC page – so do NOT create 4-5 session() values, but add a typedef or simple class to the project. And use that for passing of the values. It MUCH LESS clutter in session(), and as you about to see, it also MUCH nicer for transferring these values to Viewstate.

So, we now have this:

we adopt and use View Sate for each page.
we ONLY use session to pass values to next page.

Lets give a simple example.

We say have a grid of hotels – you pick one. As noted, for buying things, picking hotel etc, then passing that value with session is OK AS LONG as you adopt the above rule (that we transfer values to Viewstate in the target page).

The goal here is to allow multiple working tabs or copies of the browser running, and of course minimal code changes.

So, say we have a GridView, and a Hotel to book.

So, note the values we pass (hotel ID, room type, nightly rate).

As noted, we then navigate to the next page (probably additional room details, etc.) – confirm booking etc.

But, as we noted, we can’t use session() anymore, since they might have two browsers open. Heck they might have the page open on both their desktop and their smartphone.

So, when we land on the 2nd page, if two pages land using session, we in huge trouble? No, not with our above approach.

So we can still use session() to pass values, BUT we do NOT persist values on that target page. In other words, we break down the two issues:

a) - we using session() to pass values to the next page
b) - we now are NOT using session() to persist values on CURRENT page <<--- this we fix!!!

So, by making our goal here CRYSTAL CLEAR then you as a developer can deal with the above with a SIMPLE change to your existing code. As I stated, you the developer have to code, build, and design your web pages with the above concepts in mind.

So, for persisting values on a given page, just start using ViewState in place of session() – such code will work un-changed in most cases, and all and any values you save ONLY BELONG to the current page.

Only major difference is a user refresh of the page can re-set the ViewState for that page (but session() would and did persist – so some caution is required here – but not much).

So do this:

Pass values by session(), but on FIRST PAGE load (IsPostBack = False), transfer the value(s) to view state, and you are done!!

So, while session() can and is and will be shared between even two browsers running? Well, you click on some row, get PK into session(). Now, say you jump to the next page, on page load (IsPostBack = false), you transfer session value(s) to ViewState, and now you have full operational page – not dependent on Session().

The above is the best solution I have found, and you don’t in most cases have to change your code, or introduced some mucked up URL which I find is even more of mess.