views:

56

answers:

3

I have been asked to work of a very large web application and deploy it. The problem that I'm facing here is that when I deploy the application and more that 1 user logs into the system, the sessions seem to cross over i.e:

Person A logs in and works on the site, all good. When person B logs in, person A will then be logged in as person B as well.

I have been asked to work of a very large web application and deploy it. The problem that I'm facing here is that when I deploy the application and more that 1 user logs into the system, the sessions seem to cross over i.e:

Person A logs in and works on the site, all good. When person B logs in, person A will then be logged in as person B as well.

If anyone has experienced this behaviour before and can steer me in the right direction, that would be first prize, Second prize would be to show me how I can debug this situation so that I can find out where the problem is and fix it.

Some information about the application. From what I've been told and what I've seen within the app is that it started as a .Net 1.1 application and got upgraded to .Net 2 and that's why the log in system was done the way it is. (The application is huge and now complete and that's why I cant rewrite the whole user authentication process, it will just take to long and I don't know what effect it might have)

All the Logged in User information is stored in properties that have been added in the Global.asax.vb file. (could this be the problem?)

Any help here would be greatly appreciated

A: 

We had a similar situation in our code done by a vendor. In our case the probplem was due the use of global static variables assigned from session.

Kashif Awan
A: 

I don't suppose by any chance that when the user's identity is read from the session it's being stored in a static field rather than an instance field in a base class is it? And then being written back to the session from there? I've come across this before.

David M
I guess this mistake is not that infrequent :)
Kashif Awan
In standard forms authentication, the user identity (and principal) is constructed from the `FormsAuthenticationTicket` (http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.aspx) that is instantiated from the data in the authentication cookie.
Russ Cam
All the user information is set to Public Shared Properties in the Global.asax.vb file.
Organ Grinding Monkey
@Monkey: The `Shared` keyword is used to create static members, so the properties are static. And even if they weren't static, properties in the `Global` object are still shared by all users.
Guffa
+1  A: 

Sessions on the server doesn't cross over, so the actual reason has to be that there isn't actually two separate users, or that the information isn't actually stored in separate sessions.

Browser sessions

When you open a new browser window from another window in Internet Explorer, they are in the same browser instance, and thus still the same user. There is no way for the server to distinguish between the windows based on the session id, as they share the cookies and send the same id. You have to start a new instance to log in as a separate user.

In Firefox there is ever only one instance. Even if you try to start another instance, it will just open a window in the existing instance. Thus, you can not log in as separate users in separate windows.

Session objects

To store information in the user's session, you actually have to store it in the Session object. If you create properties in the GLobal object in global.asax, they are shared by all users. Even if you are in a method like Session_Start, the user doesn't have a separate instance of the Global object.

Guffa