Session IDs not unique?

[Guest]

A user of one of our sites recently reported that they were "seeing someone
else's data". Naturally, this got many people in the organization VERY
concerned and I began to try and troubleshoot. Upon inspecting some custom
logs that our application keeps (in SQL server tables) I found that at the
time this user was on the site there were 7 users that signed in to our site
and were using the same session ID. These users all logged in over the
course of ~20 minutes. Getting curious, I check the logs for past
occurrences of this and found about 20 occurrences over the last year and
half. Each time within a time span of ~30 mins. several users signed in and
our log entry reports the same session ID for them.

I know it sounds unlikely that ASP.NET is assigning the same session ID to
multiple users (thus causing them to share session state) but everything I am
seeing so far is indicating that this is in fact the case. Can anyone think
of a scenario that could cause this to happen or seem like it is happening?

Thanks in advance for your help,
Joe

 

[Guest]

We seem to have the same problem. Did you try turning off kernel output cache?
prash

 

[Guest]

prash,

The more I think about it and the more I learn about this kernel output
cache issue the more suspicious I am that this is causing my problem. I'm
definetly using IIS 6, and I'm guessing that I am using output caching on
some page that also uses session state. Additionaly, there must be some rare
scenario where a user requests the page that has output caching enabled
without having a current session cookie, and the page gets cached with the
"set cookie" header. Some subsequent requests to the cached page will then
switch users session id. Won't happen to everyone only those requesting the
page that got cached. The fact that it happens for a period of ~20 minutes
sure sounds like caching.

Thanks for the tip, I will respond to this post when I get verification one
way or another.

For others out there, here are some important links:

http://support.microsoft.com/default.aspx/kb/917072

http://msdn.microsoft.com/msdnmag/issues/06/07/WebAppFollies/default.aspx#S2

The second link is much more informative. If the author is correct however,
this is an ASP.NET bug not just a wierd scenario gottcha. Why in the world
hasn't this been addressed through an SP or at least hotfix or something.
I'm also kinda surprised that this isn't something people commonly run into
(perhaps it is and I'm just in the dark).

Thanks again.

 

[Steven Cheng[MSFT]]

Hello Joe,

I think Prash and Bruce's analysis is reasonable. I've also met some
ASP.NET web application in which the client users' data get mixed. One
common issue is using Cache, in such cases, the data specific to userA is
cached and later is rendered to userB, thus the client user will see other
user's data.

IMO, to troubleshoot such issue, we'd better first review the code logic of
the web application according to the problem data that is displaying to
client user. Is there any cached or shared(through static variables) data
in your application that may cause this problem? In addition, since your
web application is running in a production environment, it would be helpful
if you can create a simplified test application that running in a test
environment.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hello Joe,

I've performed some futher search in some former archived cases. Another
possible cause is if you're using cookieless sessionstate. In such case,
the sessionID is embeded in url string. Thus, if the url string is reused
between multiple users(copy and past into browser address bar), it will
cause the user specific data (rely on session) be mixed up.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Thanks for your reply Prash,

Yes, it does be a headache that when the problems occurs in production
environment but hard to reproduce in test/development environment.
Generally, for such product environment troubleshooting issue, we would
suggest you contact product support service if it is an urgent issue. Some
thorough debugging maybe necessary.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[rytmis]

Hi,

Yes, it does be a headache that when the problems occurs in production
environment but hard to reproduce in test/development environment.

Truer words have never been spoken.

I've had an issue like this in an application from early 2005, and the
only thing I could do was to implement a sanity check that stores the
user's details (user-agent, ip address) in the session, compares them
on each request and refuses to work if they don't match. Obviously this
causes issues for people who have an IP that may change on each
request.

Like Bruce suggested, I searched for inappropriately static variables,
but found none. Then with some rudimentary logging, I discovered that
the entire session is switched. I know about the IIS 6.0 +
outputCacheModule issue, but the related KB article narrows it down to
Set-Cookie and pages that actually use output caching. My app is a
HttpHandler with no WebForms, so no OutputCache anywhere, and it uses
cookieless sessions, so that doesn't match either. Other than that, the
symptoms seem the same.

The thing is, without being absolutely sure about a fix, I dare not
remove the sanity check, and without removing it I'll never know
whether or not the issue still exists (the check sometimes trips on
load-balanced proxies etc. so false positives are possible). A catch-22
if there ever was one.

I'm posting about this issue again in the vague hope of attracting the
attention of someone in the know.

Thanks, and sorry for digging up an old thread.

- Lauri