ASP.NET session id shared amongst browser tabs

Question

I've recently been developing a website using asp.net webforms that uses in proc sessions and I noticed that session ids are shared amongst browser tabs. So I was wondering what you would do for the following situations:

Problem: Multiple logins with different users in the one browser problem

1. User opens browser tab 1, logins with "user1" - store in session
2. User opens browser tab 2, logins with "user2" - store in session
3. At this stage session information is now pointing to "user2" because of how session id is shared amongst browser tabs
4. User tries an action on tab 1 and suddenly they have "user2" information

How do you alert the user in tab 1 that the user has changed or how do force tab1 user to logout?

My initial thought was to keep a list of active users with session id via database or application object, but the problem I face is that in tab 1 what am I going to compare the list against, when I do a request the HttpContext.Current.User would be updated with "user2" how do I know browser tab 1 was initially for "user1"

Appreciate anyone letting me know of any alternatives or best practices for the above problem

Regards DotnetShadow

Answer 1

Why don't you warn when user2 logs in instead? With a message like "You are already logged in as user1, are you sure you want to login again as another user?"

Answer 2

That's just how it is. You can't do much about it. Users are now accustomed to this behavior as it is consistent among famous internet sites like gmail, etc... so it shouldn't be much of a problem to them.

Answer 3

All tabs in a browser belong to the same instance, so all tabs share cookies and sessions, there isnt much you can do about it. If you want to implement this badly the only solution that comes to mind is carrying a unique session id with each URL. Based on that unique id you can link a specific user. You will need customize the session logic and would have to make sure all links in your website carry this unique id. It could be done with alot of effort but the real question is , is it worth doing?

Answer 4

What I do to avoid this problem is redirect to append a short, random in-url login-identifier.

Then, rather than use session directly, I store a strongly typed object in the session vars under the random in-url code, and use that object for session storage. If you want to keep it simple, you could use a Dictionary. In addition to the normal session timeout, you should keep track of the last usage within each login-id and manually time-out a session if it's too old to avoid new users from keeping old logins alive.

Essentially then, each ASP.NET session corresponds to any number of login sessions.

This has the following advantages:

• You can log in as multiple users simultaneously. That's handy to be able to do for many sites.
• In public terminals, it helps avoid accidental session hijacking. When a user leaves a public terminal, closes the webapp tab but not the browser (which is quite common) and another person then approaches that terminal and opens a new window or tab to your site, this new user sees no trace of the previously logged in user. Of course, users should log out, and anyone can inspect the history, but there's no reason to invite abuse.
• CSRF attacks against your site are a little bit harder since a url without the random login-id is meaningless.
• The implemenation is quite simple if you use a hashtable - after all, any sessionstate-consumer already is written to store and retrieve data from a hashtable, you just need to change the hashtable it's using and should ideally include a custom timeout.

The obvious downside is that you need to include the random code in the url; and that you need a bit of extra implementation. You might hide the extra code using an iframe and/or javascript+XHR based site, but doing so is a much more invasive change to a site. Finally, note that cookieless sessions are not the same; though they're simpler to turn on, they involve a much longer less human-friendly url token, and by lacking the normal cookie session token, also are less secure vs. session hijacking (since suddenly any other program or even machine that discovers the session ID can pretend to be that user).

Answer 5

Some have suggested adding uniquifiers into the URL, and tracking based on those.

If you're going to do this, you may as well just let ASP.Net do this for you by turning on cookieless sessions - it then uses the URL to contain the session ID.

Answer 6

How about storing the data in viewstate? That would be unique to every window.