需要有关ASP.Net或IIS请求URL处理的建议

Question

Environment:

• Server 2008
• IIS 7, integrated mode
• .Net 4
• ASP.NET WebForms Routing (which uses the same .dll as MVC routing, though I'm not sure which version)
• Cookieless sessions (session ID travels around on the user's URL).

We have an application that uses routing to identify which organization a user is associated with. The URL will take the form domain/Organization/OrganizationSubCategory. The user follows their custom URL and sees a landing page. When they hit next, they are directed to a page that collects some demographic info, then they hit next to proceed to the application. When they do, the user is added (if necessary) to their organization in our database. After the initial landing page, routing no longer applies - the user is directed to regular aspx pages.

The site is receiving a fair amount of users entering the app; an average of 850 per day.

The problem is that a small number (less than 1%) of users are getting added to the wrong organization.

We are logging information on the landing page and when they submit the demographic page. One thing we log is Request.RawUrl. We started noticing users who are associated with one organization being logged as having requested the full correct URL (including the sub-category) of another organization. Sometimes nobody legitimately came in following the incorrect organization URL even in the same day. We've had people report directly that they just created the "sub category" (using an administrative application), instructed a user to follow their unique URL, and yet the logs show an entirely different URL for that very user (I know it's that user because I'm logging email address and session ID so I can associate the same user's path through the landing page and the demographic page). It's as if IIS is sometimes creating a new session, and simply assigning some previously requested URL to that user.

In an attempt to eliminate some sort of caching, we have:

• Set the config httpRuntime element's enableKernelOutputCache attribute to false
• Disabled caching in IIS settings
• Set the config sessionState element's regenerateExpiredSessionId attribute to false (even though we haven't seen the session ids being re-used).

Other suggestions?

Answer 1

Are these internal users? Are there proxy considerations? That wouldn't explain a wrong url though. Are you 100% certain the users were given url A and they show up with URL b? Do you have any routing modules currently assigned? Are you sure its not getting rewritten by a rule in another module?

Could this be an application issue where their 'new user' email (for ex) contains the wrong url?

Answer 2

Well, we still don't know with complete confidence, but it seems that users in one organization were most likely searching the Internet to find URLs into the system and following those.
I can't explain the report we had as I described in the original post.
When I tried to enhance logging to capture pre-post session creation to prove it for sure, the logging on the begin request event worked in our QA environment (same as production), but just flat wouldn't work in production. I could never determine why.