Why does a request for a .gif image cause the session_start event to fire in my asp.net application?
In my local IIS I tried setting up a module mapping for *.gif pointing to StaticFileModule thinking that would prevent IIS from routing the request through asp.net, but for some reason my session start event is still firing when just requesting this single image.
Can anyone advise what needs to be set in IIS to prevent this from happening?
Thanks
I think you may also have to disable Session State for those folders:
https://serverfault.com/questions/77852/is-it-possible-to-set-a-folder-as-cookieless-in-iis7
Do you have a modules section within your web.config which has runAllManagedModulesForAllRequests set to true? This causes all requests (including .gif, .jpg, etc) to go through asp.net, not just managed ones.
Anything like this:
<modules runAllManagedModulesForAllRequests="true">
...
</modules>
Or alternatively, have you defined any custom <httpHandlers> within your web.config?
It sounds like your CRM might be causing the asp.net runtime to handle the request (is it a seperate .NET app? and if so, what about it's web.config?)
Related
I have the need to secure an entire folder of static HTML files. The intention is that a user cannot access these files unless they are authenticated and have the necessary role.
We've got cookie-based authentication set up using OWIN, but no matter what I try I can't seem to figure out the correct combination of changes to make to require authentication on the folder.
The first problem is that IIS is skipping ASP.NET completely and just serving the files. I think there's probably a way around that by setting runAllManagedModulesForAllRequests to true. But where do I go from there?
I've tried stuffing elements in the Web.config to require the proper roles, but it just results in EVERY request getting denied (presumably because it's not inspecting the proper cookie or something).
I've spent my entire day on this and I'm about to lose my mind.
Has anyone solved this problem?
IIS is serving static files , if you want to stop this you can remove default static file handler and than every request is
serverd by MVC/OWIN.
Than make static file handling and authorization in your controller
: listen/map route where static files are located
to remove default static file handler add this to web.config file:
<configuration>
<system.webServer>
<handlers>
<remove name="StaticFile" />
</handlers>
</system.webServer>
</configuration>
I'm looking for a more precise solution to handle requests for static contents by the ASP.NET lifecycle without setting runAllManagedModulesForAllRequests to true.
As far as I know is the effect of runAllManagedModulesForAllRequests = "true" that the precondition attribute of each module will be set to "".
The problem:
I have to protect static content in a subfolder of a web application against unauthorized access
To include requests to those static contents in the ASP.NET lifecycle and therefore having some events fired, I set runAllManagedModulesForAllRequests to true in web.config.
Because this solution turns the big wheel and all managed modules are affected for the whole application, I'm looking for a more adapted solution restricted to the subfolder where this behavior is required.
I need a solution for IIS6 and II7
Question 1:
The preconditon of which modules have to be resetted (precondition = "") to fire global.asax.cs events (e.g. Application_BeginRequest) for requests for static contents?
Question 2:
Is it possible to limit this request handling to requests to a single subfolder (e.g. perhaps by placing an adapted web.config in this subfolder, tweeking the main web.config, ...)
Any suggestions would be appreciated. Thanks.
Have you thought in the direction of registering a custom HttpModule for the right event of global.asax, and then enabling the HttpModule only for the sub directory using location attribute in the main web.config itself? It is just a thought of a possible solution - I havent thought through it..
<location path="subDirectoryPath">
<system.web>
<httpmodules>
<add type="MyCustomModule.Name" name="MyCustomModule" />
</httpmodules>
</system.web>
</location>
EDIT:
You may have to override your web.config, and bring in all the httpModule section in this, and then insert the custom module at the right place, with the right precondition.
This is to avoid setting runAllManagedModulesForAllRequests to true
I've created an httpModule to handle URL remappings, and it works great on my test system. A request for www.mydomain.com/Some_Fancy_URL gets rewritten to www.mydomain.com/some.aspx?fancy=23 and so on.
When I deploy to the actual web site, I'm getting the default IIS 404 page though.
After doing some research online, it would seem that I need to setup "Wildcard Mapping" in IIS 6 to get the request past IIS and in to my httpModule. The problem is that the site is hosted on a shared server, so it may not be possible to get the ISP to make that change.
My question is, can't I use an httpHandler to tell IIS how I want these requests handled? For example:
<httpHandlers>
<add path="*.aspx" verb="GET,POST" type="System.Web.UI.PageHandlerFactory" validate="false"/>
</httpHandlers>
It would seem like adding this to my Web.Config should tell IIS to stop validating the existence of .aspx files, and just pass the request along for me to process. It doesn't work though.
Any suggestions?
The problem with IIS 6 and ASP.NET is that they're aren't integrated. IIS needs to be told about ASP.NET via script mappings (.aspx, .asmx, wildcard and so on).
None of your web.config configuration settings will influence IIS because web.config is there to configure ASP.NET's behaviour, not IIS. IIS has no knowledge of web.config.
Unless you can hand off a request to the ASP.NET pipeline (via a script map) nothing will happen and all your web.config settings will be ignored.
With IIS 7 the story is quite different. In IIS7, ASP.NET and IIS are closely integrated and share the same pipeline thus permitting you to achieve the result you're looking for.
The alternative may be to find out if your hoster runs a URL rewriter such as ISAPI_Rewrite on their servers. That way you could rewrite urls without having to map a wildcard scriptmap to IIS6.
Through some trial and error, along with more web searches, I found a solution. It essentially parallels Kev's answer.
IIS won't treat a request as .NET unless it has a known file extension (.aspx, .ascx, etc.). When I send along something like www.mydomain.com/anything it looks for a file or folder named "anything", and when it doesn't find one, it just drops off to the default IIS 404 handler.
That's where I took over. I changed IIS 6 to forward 404 problems to /404.aspx. I then created that page with a generic "Your file wasn't found" message in the same style as my web site.
Here's the good part: Now that IIS is sending 404's to a .NET page, the custom httpModule I created is getting fired. The request is for 404.aspx, but IIS is nice enough to also append the original URL as well. You get something like:
www.mydomain.com/404.aspx?404;http://www.mydomain.com/anything
This allows me to parse the request in the httpModule, and rewrite as needed!
I have an IHttpHandler registered like this:
<httpHandlers>
<add verb="*" path="*" type="MindTouch.Dream.Http.HttpHandler, mindtouch.core"/>
</httpHandlers>
Which catches /foo, /foo/bar, etc. just fine, but on / the Visual Studio built-in server does not hit hit either the HttpApplication or my handler.
That's the way to do it. Your web server/site will have a setting which specifies the default document to serve for a directory. If not present or not set, the web server will attempt to serve either the directory listing which should be turned off for security, a security error if the listing is not available, or nothing.
So in your case prior to the default document existing, "/" was not actually making an application request.
I fixed it and I think I recall this being an ancient ASP.NET issue:
I created a file called Default.htm, which ASP.NET will try to resolve the / path to and since there is now a real path to resolve to, the HttpApplication gets called, incidentally with a path of /default.htm.
Is there a less hacky solution to this? Gladly would accept a different answer than my own :)
I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.
The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.
When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.
[Note: I've also tried extensionless URLs and they exhibit the same problem]
The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.
So I am left with several questions:
Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
Why does it work in VWD 2008, but not IIS7?
What changed from IIS6 => IIS7 that could have caused this?
Any other thoughts on workarounds?
[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]
Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:
<modules runAllManagedModulesForAllRequests="true">
After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.
Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:
<system.webServer>
<modules>
<remove name="Session" />
<add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.
This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Microsoft included a fix for this issue (at least for extensionless urls) in Service Pack 1 for Win7 and Windows Server 2008 R2:
http://www.microsoft.com/download/en/details.aspx?id=5842
Also available as a hotfix: http://support.microsoft.com/kb/980368
After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.
After applying SP1 or the hotfix, no web.config changes are needed to make the session and forms auth work for extensionless URLs rewritten to asp.net pages/handlers/etc.
I don't know if this fixes anything for rewrites to static file extensions like .htm. My guess is, probably not. I would try to avoid setting runAllManagedModulesForAllRequests="true" in production environments, because it adds unnecessary overhead on static file requests.