IIS7 Integrated Mode - Bypass Forms Auth for static files - asp.net

I have a ASP.NET MVC app on IIS7 using Forms Authentication in Integrated Mode. I am noticing that the ASP.NET runtime is being hit for every request that comes in even if it is only for static files (probably because of Integrated Mode). Is there a way to configure IIS7 to serve up static files without hitting ASP.NET?
I've been thinking that the only way around this is to create a separate virtual directory just for static files -- a mini-CDN, if you will.
Any other ideas?

To avoid having your HttpModule called for static files, configure it in web.config to use preCondition="managedHandler".
In case it helps, event handlers in Global.asax are not called for static files.
Also, be aware that all HttpModules are called for all files when you're testing with Cassini.

Related

Static content and ASP.NET SQL sessions

Here's my scenario:
Using SQL Server sessions (due to web farm)
customErrors is On using redirect
There is a membership provider that uses sessions to store user information
In web.config, there are <location> sections that <allow users="*">. This is used for static content (e.g. images)
Whenever I try to access the error page or even static content, the session tries to start up (probably due to membership provider). If the SQL Server is down, that throws an exception.
Is there any way to prevent the membership provider and/or sessions from trying to initialize when I'm accessing certain folders (i.e. static content)?
It turns out most of my problem is because of differences between IIS6, IIS7, and the development server:
http://www.asp.net/hosting/tutorials/core-differences-between-iis-and-the-asp-net-development-server-cs
In IIS 6, ASP.NET only runs for extensions that are configured under Site properties > Virtual Directory > Configuration > Mappings > Application extensions. For example, .aspx points to aspnet_isapi.dll. Static content will not go through the ASP.NET by default.
In IIS 7, it's similar (under Handler Mappings), however thanks to the new integrated pipeline, in the web.config you can also have static content check for authentication. See Performing Forms-Based Authentication and URL Authentication on Static Files with IIS 7 in the URL above.
Also based on the above URL, in the ASP.NET Development Server (based on Cassini):
Every request that comes into the
ASP.NET Development Server, whether
for an ASP.NET page, an image, or a
JavaScript file, is processed by the
ASP.NET runtime.

BeginRequest fires for static files in ASP.NET MVC app

I was under the impression that static files (CSS, images, #font-face files, etc) bypassed ASP.NET completely, and were served directly by IIS.
However, my BeginRequest event handler is being called for every HTTP request, including those for static files. This concerns me because I'm creating an Entity Framework data context to be used for the lifetime of each request in that event handler. I don't want to create those contexts if they're never going to be used.
I'm using IIS 7 on Windows 7 Ultimate with no special handler mappings defined. Do I have it wrong? Should these events be firing?
I believe a default ASP.NET MVC site has this set in the web.config.
<modules runAllManagedModulesForAllRequests="true" />
This means every .NET module will be loaded for every IIS request. This is required for ASP.NET MVC to handle extension-less routing. It's essentially a wildcard mapping that you would write in IIS that would match everything and route it to ASP.NET that lives in the web.config.
Read more here, including a way to disable the behavior if you aren't using .NET 4.0. It is nasty, but it's the cleanest solution for sites that can't deal with the overhead of having static files served by asp.net.
BeginRequest will be triggered for all requests (including static content) if:
You're using Visual Studio's development web server.
You've configured IIS to do so.
Please take a look at:
http://forums.asp.net/t/1220664.aspx
In addition to fixing the issue for your static files, you could use Lazy initialization Lazy<T> for your ObjectContext: http://msdn.microsoft.com/en-us/library/dd997286.aspx
The integrated mode in IIS 7 works differently than it was before.
You could switch to classic mode if desired.
Alternatively you can define your custom route handler and do the context initialization there. That way it's only done for specific routes.

ASP.NET ascx.cs via GET

Say I have this url:
http://site.example/dir/
In this folder I have these files: test.ascx.cs and test.ascx
Just to be clear, I am not a .NET developer.
From a security point of view - why can't I access http://site.example/dir/test.ascx.cs and how secure is it to keep those files there?
I assume IIS filters out request that query these kind of files, but can someone explain me this?
Thank you.
You just explained it yourself. IIS won't serve those files.
When you register ASP.NET with IIS (aspnet_regiis.exe) it will add common extensions and associate them with the ASP.NET handler. As far as the .cs extension is concerned it is filtered and not served by IIS. It is absolutely safe to have these files there, but I would recommend you to use an ASP.NET application project (in contrast to ASP.NET website) which is precompiled and you don't need to deploy source code files on your server.
(source: wewill.cn)

Processing static files via HttpModule in ASP.NET

I have statiс files in website folder, but need to check permissions for every file.
I decided to use HttpModule for that purposes.
ASP.NET receives all the http-requests (I used wildcard mapping) and
The algorith is the following:
HttpModule receives the request
HttpModule checks permissions
If access is denied then the answer is "Forbidden". If all is OK then httpModule's method just returns.
DefaultHttpHandler is automatically used to process request for static files
The problem is that DefaultHttpHandler is not effective enough (it doesn't use file cache, etc.). But IIS (without ASP.NET) works with static files in a very good way.
All I want is to let IIS serve static files after my checks.
Is there any way to implement it?
If you're using IIS7 then yes, it's quite easy. In the integrated mode, all requests go through the managed pipeline. Let IIS serve the files, but add a HttpHandler to do the checks. Or you can use one of the authorization methods that ASP.NET offers.
I have a solution that could be used to stream the file in IIS 6. It does all the good things like resumable downloads, client side caching (etag & expires) and server side caching.
http://code.google.com/p/talifun-web/wiki/StaticFileHandler
It should be easy enough to extend to include authorization before serving up the file.

using system.web.authorization settings in web.config to protect classic asp files?

I've got a virtual directory with a vast subfolder hierarchy and thousands of classic ASP files, all of which have varying permissions set at the NT folder level (don't ask.. shakes head).
Is there any way to setup all these virtual directories with their own web.config so i can control access via configuring system.web.authorization parameters therein and doing away with folder level permissions?
I've tried and so far have only been able to have this work on asp.net files, not classic ASP.
If it isn't possible, can someone offer some alternatives?
Because clasic ASP has no idea about the ASP.NET runtime due to the fact that it is a) classic and 2) isn't .NET, you can't use the .NET configuration to manage the permissions.
Your options though would be:
Upgrade to IIS7
Rename all you asp pages to aspx
Change your asp handler to aspnet_isapi.dll (which is the .net handler)
While 2 and 3 may work you will need to completly test these pages to make sure that they still work as intended.
I would say the best bet would be to just use the file system ACLs to control who can access the folders. Just because you don't understand them doesn't mean that they don't have their place.
You can use wildcard mapping so that all file types will be handled by the ASP.NET runtime in IIS6; however, even with this turned on permissions are not handled through the web.config. Windows authentication in both classic and .NET uses the file permissions to determine access.

Resources