Good day all,

working on a portal that uses role based security which is in its final phase of testing, but in the course of testing, i found out that if i login as a normal user to do some things on the portal, and i quickly want to use the admin back end (ie, log in with a different admin account other than a normal user)to either approve what i did as a normal user so that flow can continue.(by opening another browser window.) i discovered that immediately i login as the admin user, the user session that holds the role with which to display menus to be presented pending which user, for the normal user in the previous window is automatically erased and that of the new login (admin) takes over and vise versa.

i do not want this because it is a heavy traffic site, with most of them using cyber cafes to access the application, and to beat crowd, the cafe might be tempted to open multiple browsers and or multiple browser tabs to access the application on the same system!

the question now is, is there a way to stop this from happening expecially from the session end?

please answers would be appreciated.

note:the site was implemented in .net2.0.

Need more details.

How are you storing your session-specific data?  Are you using the Session object?  Or profiles?  Or something else?

How are you implementing roles and membership?  Are you using the built-in .NET providers, or something custom?

Have you looked at the conversation using a web debugger like Fiddler, to see what's happening with cookies?

G'Day Nelly,

If you have multiple windows open in the same browser they are going to share the same cookies and therefore same session (I'm assuming you are using the default cookie based session state in ASP.NET).

So if you login a new window as an admin user, you are then seeing your previous window (which had the non-admin user logged in) suddenly start to react as the same admin user as well. Is this what you are saying?

Not really a worry unless youa re using the "Same PC" as a non-admin user at the "Same Time". Am I on the right track?

exactly what i am sayin with respect to your second paragraph.

i will not use the same pc for both admin and non admin functions at the same time.

but there is every possibility that two non admin logins from the different browser windows from the same pc will try to login to the app, and i want to prevent any of such.

Yes i am using the in built .net membership.

nellyihu:

but there is every possibility that two non admin logins from the different browser windows from the same pc will try to login to the app, and i want to prevent any of such.

When a user tries to login, would it work to check to see if they are already logged in, and if they are, to display a message saying that they need to logout first?  That wouldn't force a separate window to close, but it should help prevent user confusion.

yes, i know but that is for a user say "A" that is logged in and wants to re-log in again into the app using a seperate broswser window on the same machine.

but what about this senario where user A is logged in and also, another say user "B"  is also logged in in a different browser on the same machine!

this is the kind of senario i am trying to avoid in the cyber cafe!!

Do you mean one person might be logged-on as user A in IE and user B in Firefox, and you want to prevent that?

If so, the only way I know of to communicate from one browser to another is to use Silverlight.  You can store the user's details in common isolated storage, which you can read or write from both browsers.

exactly... could be IE and IE, or IE and FF.

pls how can this be done using silverlight?

For IE and IE, the different browser instances will share cookies (provided they're running under the same account on the same machine).  That doesn't work for IE and FF.

To write to isolated storage, you could use something like this:

IsolatedStorageSettings.SiteSettings["key"] = value;

To read from it:

string value = null;
IsolatedStorageSettings.SiteSettings.TryGetValue("key", out value);

The value that you read and write would probably be something like the user ID and the time the user logged-on, or maybe the time the session was last renewed, or the time of last page access.  You could get that value from a cookie or from a web services call.

Since you can read isolated storage from a Silverlight app running in both IE and FF, you can use that info to implement the logic you described.

I don't have a detailed example on my web site yet, but I do have one in my book, in case that's of any interest.

ok, thanks, the info was usefull, will find out more from your book.

another question that keeps bothering me with sessions, expecially with respect to logged in user,

how do one check and know that it is still the same currently logged on user? we knw for instance that when a user is logged in to an app, a new session id is generated for that user, how do i ensure that, it is the same user id that is still logged on pending the time the user wishes to discontinue with that session again by loggin out?

Sessions are associated with a browser, not with a logged-on user.

I suppose you could write a custom session provider that uses the logged-on user ID as the session ID, but that's not how the default implementation works.

This is yet another reason why it's a good idea to avoid sessions if you can.  Better to use cookies, Cache, SQL Server, etc when possible.  If you can't avoid Session, or you need to be able to persist per-user data to disk in between page requests, then you might consider doing something like using the user name or ID as a key to the Session object (off the top of my head; not tested):

if (this.Context.User.Identity.IsAuthenticated)
{
    string key = this.Context.User.Identity.Name;
    this.Session[key] = "my user-specific data";
}

and of course, you can do things append unique strings to the initial key to support multiple values.  You can also use this to make a transition from being an anonymous user to one who is logged-in.

With this approach, if a user logs-out, it's probably a good idea to clean up or abandon the Session object, just so it doesn't grow without bound.