 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / March 2008Cookieless sessions - ISAPI dll failing?
Hi All, Working in ASP.Net 2.0, session state set to cookieless. We recently updated the application from a 1.1 project. We've always run with cookieless sessions. Since the upgrade to 2.0, we keep getting lots of similar errors. Our error reporting gives us a message like: Time: [14/03/2008 11:44] Application Version: [2.0.0014.0] Message: [The file '/Application/(s(oqe1gv45d4gxfy45ee1ateuh))/ start.aspx' does not exist.] Source: [System.Web] TargetSite: [Void CheckVirtualFileExists(System.Web.VirtualPath)] StackTrace: BEGIN at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) END Now, if I go and look at the IIS logs, we can have something like: 2008-03-14 11:44:55 255.255.255.255 GET /Application/themes/main/css/ clientstyles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE +7.0;+Windows+NT+5.1;+InfoPath.1) https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 200 2008-03-14 11:44:56 255.255.255.255 GET /Application/themes/main/css/ styles.css - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows +NT+5.1;+InfoPath.1) https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 200 2008-03-14 11:44:56 255.255.255.255 GET /Application/scripts/ Help_Util_Validation.js - 443 - 0.0.0.0 Mozilla/4.0+(compatible;+MSIE +7.0;+Windows+NT+5.1;+InfoPath.1) https://our.domain/Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 200 2008-03-14 11:44:56 255.255.255.255 GET /Application/ (s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx hp=3 443 - 0.0.0.0 - - 302 So it looks like someone, in the middle of their session is suddenly putting a request through that isn't having the Session ID stripped - and hence the directory being requested doesn't exist, hence the ASP.Net error I notice also, in this case, that the User Agent had disappeared on this request. I don't believe (but will have to go searching) that this was true in the other cases I've seen, so may not be an issue. So what should I look for next? Are there circumstances where the ISAPI dll would fail to strip the Session ID? Or some other place I should be looking? TIA, Damien It seems to me that capital 'S' and lower case 's' makes a difference. All good requests have a capital 'S' in a beginning of the SessionID /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 The only bad request has a lower case 's' /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx You can reverse IP address it came from. Most likely it came from "bad" robot. "Bad" in terms of poorly written. That converts URLs to lower case at will... Second option is that someone has published link to your site somewhere with a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo trying to follow that link.... Solution: do not pay attention :) George. > Hi All, > [quoted text clipped - 78 lines] > TIA, > Damien > It seems to me that capital 'S' and lower case 's' makes a difference. > All good requests have a capital 'S' in a beginning of the SessionID > /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 > > The only bad request has a lower case 's' > /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx Thanks for spotting that. I'll have to go back and check I didn't just screw that up while anonymising the post, but you're right, it does look different. > You can reverse IP address it came from. Most likely it came from "bad" > robot. "Bad" in terms of poorly written. That converts URLs to lower case [quoted text clipped - 3 lines] > a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo > trying to follow that link.... I know that we do have some links from elsewhere that may have these things. It would help a lot if bots would set the Referer header (so we could find the duff sites and let the owners know) > Solution: do not pay attention :) > > George. Thanks George. Not paying attention is a good strategy, but our error reporting sends messages to our helpdesk, who raise incidents, that I have to close and give reasons on :-( I can try to get our error reporting system to ignore these errors specifically, but it'll mean having to pull apart exception messages to find what path is being accessed :-( My website sends me an email every time unexpected exception happens too. I just learned to ignore those messages. If some BOT gives me to many errors I just ban it's IP address... I guess you will have to do the same to avoid to many fake incidents from help desk George. On Mar 14, 3:23 pm, "George Ter-Saakov" <gt-...@cardone.com> wrote: > It seems to me that capital 'S' and lower case 's' makes a difference. > All good requests have a capital 'S' in a beginning of the SessionID > /Application/(S(oqe1gv45d4gxfy45ee1ateuh))/start.aspx?hp=3 > > The only bad request has a lower case 's' > /Application/(s(oqe1gv45d4gxfy45ee1ateuh))/start.aspx Thanks for spotting that. I'll have to go back and check I didn't just screw that up while anonymising the post, but you're right, it does look different. > You can reverse IP address it came from. Most likely it came from "bad" > robot. "Bad" in terms of poorly written. That converts URLs to lower case [quoted text clipped - 4 lines] > a SessionID and lowercase 's' Hence bunch of robots like Google, Yahoo > trying to follow that link.... I know that we do have some links from elsewhere that may have these things. It would help a lot if bots would set the Referer header (so we could find the duff sites and let the owners know) > Solution: do not pay attention :) > > George. Thanks George. Not paying attention is a good strategy, but our error reporting sends messages to our helpdesk, who raise incidents, that I have to close and give reasons on :-( I can try to get our error reporting system to ignore these errors specifically, but it'll mean having to pull apart exception messages to find what path is being accessed :-( > On Mar 14, 3:23 pm, "George Ter-Saakov" <gt-...@cardone.com> wrote:> It seems to me that capital 'S' and lower case 's' makes a difference. > > All good requests have a capital 'S' in a beginning of the SessionID [quoted text clipped - 6 lines] > screw that up while anonymising the post, but you're right, it does > look different. I've now verified that it does seem to be dropping everything into lowercase. (So when I anonymised, I should have had "application") > > You can reverse IP address it came from. Most likely it came from "bad" > > robot. "Bad" in terms of poorly written. That converts URLs to lower case [quoted text clipped - 7 lines] > things. It would help a lot if bots would set the Referer header (so > we could find the duff sites and let the owners know) I've now further analysed the ones that seem to fall into this pattern. I don't think it's a bot, because it can happen even quite late on in our sequential process. But the following seems to be one pattern: Client does a GET on a particular aspx page, gets a good response. Resources for that page (CSS, JS, Images) then get loaded. Then there's the weird request for the page again, all in lowercase. No User Agent, no Referer. Then, usually, the client goes on to do a postback on the page. So it looks like the second request (the one in lowercase) isn't necessarily being shown to the user. Is there some kind of popup-blocker, security software or something similar that might perform additional requests to URLs like this? I honestly don't know what to look at next. Problem is, our error system is fairly aggressive, and after an error occurs, the session gets abandoned. So the subsequent postback can't be dealt with nicely anyway. Thanks in advance again, and thanks again to George and Bruce for helping me make some sense of this. Damien most likely its an expired session, so a redirect is done for the new session. an empty user agent is usually a bot. -- bruce (sqlwork.com) > Hi All, > [quoted text clipped - 77 lines] > TIA, > Damien
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.