Hi. I hope this is the correct forum to post in. I think this is a basic problem, but I'm not sure it quite fits in "how to" either...

I'm not really an ASP developer, but have inherited a several year old ASP program with a problem, and am stuck as to how to fix this problem.

The application is an ASP app using a Sql Server 2000 back end, w/ IIS 5.5. It uses NT authentication. We use BigIP for
load balancing across 4 servers, and have enabled active cookies for state maintenance w/in BigIP. An employee_ID and some other basic identifying info
is stored in the cookie.

After significant log file and SQL Server Trace review, I've determined that the application is reusing existing sessions and their stored information when it
shouldn't. What happens is that a user logs in and works for a while under a session id. At some point, a second, new, session ID is created
for them. At this point, if another user logs in, they (may) be using the original users first session ID, with all of the original users identifying info. I haven't been able to isolate exactly what causes the new ID to be created in the first place, it isn't consistent. Obviously, this causes all sorts of problems, "turning one person into another" as the users say.

I'm at a loss. With the session ID tracing back to a different user, all the normal ways to ID the logged in user -- like the Logon_User server variable --
trace to the wrong person. I have determined that IIS logs the cs_Username for the user that's really sitting at the computer, the "correct" user. If I could find a way within the ASP code to pick up that cs_Username, I could circumvent the problem by modifying the session state check include file, but I've had no luck.

This is driving me crazy. It's been a standing issue for a very long time, and I'd really like to fix it. Can anyone point me in the right direction or give me some pointers?

Thanks very much!

;;;I've determined that the application is reusing existing sessions and their stored information when it shouldn't.

If the userId is unique (as it should be) this shouldnt be possible.

;;;An employee_ID and some other basic identifying info is stored in the cookie
Where does the employee_ID come from? It should come from the auto incrimenting primary key (unique) field in your users table. I store this value in a session variable.


Wind is your friend
Matt

The user ID is definately unique, and is coming from an auto-increment field in the database as you suggest. The problem is with the session bumping into each other, causing one persons unique employee ID to be used by another. The database is fine-- the problem occurs either within BigIP (my suspicion) or IIS and their session reuse habits.

;;;The problem is with the session bumping into each other, causing one persons unique employee ID to be used by another
Sessions do not bump into each other. I do not undestand how this is possible if as you say - the following is happening?:
1..User logs in?
2..Set a session variable = to thier unique UserID?
3..Another user logs in?
2..Set a session variable = to thier unique UserID?
-------This can happen as many times as you like, aditionaly:
1..ALL sessions are independent of each other
2..If each user has a uniqueID how can one persons ID be assigned to another?

;;;IIS and their session reuse habits
I am not awaere of any such habbits. I would be following your scripting to see how these values change. Sorry I couldnt be more helpful - these behaviours as you describe them are new to me.

When you said:
;;;but have inherited a several year old ASP program
Did the application always have these problems?

Wind is your friend
Matt

1) User A Logs in, uses app for a while under session S. Session S contains his unique ID.
2) User A does something in app, causing session T to be created. Session T contains his unique ID.
3) User B goes into app, and for whatever reason logs in under session S, w/ user A's unique ID.

Remember, it's using NT authentication, so the users never actually enter that stuff in, IIS "knows" who they are without intervention. I'm pretty sure the problem is that big IP doesn't give IIS what it needs to recognize reliably where the request is actually coming from, causing it to 1) create sessions that don't need to be created and 2) periodically reuse sessions erroniously.


I've got an IIS log file at the link below that records this oddity. It's color coded, green for one user, orange for the other, and a bold line where one person "became" the other. You can see the session info that I have it writing out via "appendToLog", as well as the ASPSessionID that IIS logs on its own....
Identifying info has been changed, of course, but what happens is pretty clear...


http://home.ripway.com/2005-6/318435/ex053105.xls

It's an odd error. I've written multiple c# web apps, and more desktop apps than I can count, but this? I'm just not knowledgible enough....

;;;User A does something in app, causing session T to be created.

mmmmm - I am a little confused. Are these session variables being set using scripting? If so why do they change. A session("userID") value shouldnt need to change - This is thier unique ID used to identify them and should be coming from the PK in the users table, is it?

;;;Remember, it's using NT authentication, so the users never actually enter that stuff in,
This is just the method used to connect to the database (not sure what you mean by "never actually enter that stuff in") . Once the connection is made, you log in and get this unique ID assign it to a session variable - it never needs to change. Since they are unique no body will ever get assigned another persons value.

From what you are saying I have a feeling your application is using sessions different to how I use them - anybody else get whats going on here?





Wind is your friend
Matt