0

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?

dudeNumber4
  • 4,217
  • 7
  • 40
  • 57

2 Answers2

0

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?

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • No internal users. Proxy considerations: no 2 organizations will share the same proxy. As for how certain we are that users are submitting a different URL than the one they are directed to: virtually 100%. We didn't believe it at all for the longest time until the one example I cited: the admin directed the user to the URL just created, and the user's Request.RawUrl was *completely* different (the possibility that they correctly constructed the incorrect URL is nil). No routing modules. Some URLs are sent out in emails/reports, but those don't seem to be the issue. – dudeNumber4 Sep 30 '11 at 21:06
  • Any output caching enabled in the app? – Adam Tuliper Sep 30 '11 at 21:56
  • Also raw URL isn't always the URL they requested if I remember correctly. We had a posting on here recently on this. I'll have to check this – Adam Tuliper Sep 30 '11 at 21:57
  • Output caching would only control what was received, not which URL IIS is matching with which user, correct? – dudeNumber4 Oct 03 '11 at 15:33
  • I've read (not experienced) of very unexpected results with outputcaching in MVC especially when dealing with auth so just want to exclude that from thought if possible. – Adam Tuliper Oct 04 '11 at 00:42
  • Log the cache_URL and http_url headers - do they all match? What routes are setup? Only default or others? I have to guess that an incorrect route is changing the URL . Log the URL plus a unique request Id before routing occurs and then after. Off the top of ny head not sure which event this could fall under you may need your own custom rote class. – Adam Tuliper Oct 04 '11 at 00:47
  • Also try some route unit tests against the ones that caused you issues. There are various posts on the net for setting that up. Something may come to light there as well. – Adam Tuliper Oct 04 '11 at 00:54
  • Reference output caching - it's WebForms, not MVC. As for routes, there are about 6, but the ones causing the error are by far the most used. It doesn't seem like there is an error in a route itself since the error is only seen during busy periods and less than 1% of the time. – dudeNumber4 Oct 04 '11 at 16:32
  • As for logging those server vars before and after routing, yes, I'm going to do that, but it's going to be tricky. I assume I can log before in the application BeginRequest event, but in order to tie that user to the same user logged on the landing page, I'll have to use UserHostAddress (their IP). If coming through a proxy, though, the URL should still be from the same organization... – dudeNumber4 Oct 04 '11 at 16:35
  • After looking into it, I don't see headers by those names (CACHE_URL, HTTP_URL). I thought they would be in the server variables collection, but they're not. – dudeNumber4 Oct 05 '11 at 13:46
  • note Lucero's response here: http://stackoverflow.com/questions/757806/get-the-exact-url-the-user-typed-into-the-browser – Adam Tuliper Oct 07 '11 at 15:05
0

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.

dudeNumber4
  • 4,217
  • 7
  • 40
  • 57