I've got informed that following the general Microsoft recommendation our web servers will be reconfigured; among other things the allowSubDirConfig setting should be set to false. Thus, our ASP.NET applications must use a single Web.config at their root level (which is quite okay for our applications by the way).
However, ASP.NET MVC uses a "non root level" configuration file (by default!) for the Views directory, which contains a simple (but important?) web server related section:
<system.webServer>
<handlers>
<remove name="BlockViewHandler" />
<add name="BlockViewHandler"
path="*"
verb="*"
preCondition="integratedMode"
type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
Regarding to a post by Phil Haack this is security related, hence important.
Since the other .NET Framework related sections still work, because the ASP.NET runtime does not obey the allowSubDirConfig setting, an ASP.NET MVC application still works too. So the ignored web server configuration doesn't really attract attention during general usage, although i've a bad feeling about it.
Isn't that a lousy idea? If web servers are configured that way (by recommendation), how vulnerable are those ASP.NET MVC applications out there?
The HttpNotFoundHandler has a path attribute which means you can add it to the root config file and point path to the Views folders and you would not be altering the security level in any way:
<system.webServer>
<handlers>
<remove name="BlockViewHandler"/>
<add name="BlockViewHandler" path="Views/*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
This will work with a basic web.config file, but beware if you are adding/removing handlers as part of your application. Handlers that come before the BlockViewHandler could still deliver content from the Views subfolder (but then I believe this is also the case with the standard web.config in the Views directory unless you remove the handler there specifically).
Generally speaking IIS will not serve .cshtml files from the Views folder (unless specifically allowed) even if the system.webServer section is missing/ignored in the Views subdirectory.
But it would serve other files (e.g. html,css,js) which would be blocked by the BlockViewHandler handler which could be regarded as reduced security.
Related
I have .net web application which includes a reference to OWIN.
This is all working fine and is serving up an web application using OWIN happily.
I want to include in the same web application an aspx web page. Is there a way I can inform my web application not to use OWIN for a single page (or a path).
From investigation it looks like this might not be possible.
There are a couple of handler mappings which are at play.
System.Web.UI.PageHandlerFactory handles aspx pages
Microsoft.Owin.Host.SystemWeb.OwinHttpHandler handles owin request
I can add them seperately and get close to what I require
i.e:
<system.webServer>
<handlers>
<clear />
<add name="OWIN" path="test" verb="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler" />
</handlers>
</system.webServer>
This will allow serve up owin stuff from a targetted path (test in mycase)
and
<system.webServer>
<handlers>
<clear />
<add name="APSX" path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory"/>
</handlers>
</system.webServer>
Will allow me serve up an aspx page - but only if the OWIN dlls are not in the bin directory.
If the OWIN dlls are present then the PageHandlerFactory will drop into OWIN handler and serve up via OWIN making. I.e. even though the OwinHttpHander is not specified, it still kicks into OWIN. I'm guessing this is built into the PageHandlerFactory code.
As far as I can tell, this means that you can never have an aspx page in the same web application which uses Katana (because it need the OWIN dlls, and then PageHandlerFactory calls into the OWIN code rather than aspx - deduced from testing rather than proved out right).
So this is a bit of asp.net I feel like way too many people don't understand. That is to say, I don't understand it and I've asked a bunch of people/googled and no one else seems to know the specifics either.
By default ASP.Net applications will serve files in Content and Scripts directories as static content. In fact, if I create other directories, I think it will serve static content in these as well.
However, the contents of some directories won't be served - the typical Asp.Net Mvc Controllers directory for example. In addition, you can always configure routes in asp.net (or OWIN handlers) that will pick up certain routes but not either.
Nothing seems to be configured anywhere. I have my suspicions, but I'm really not clear on what exactly is the rule for what gets served as static content and what gets processed by asp.net?
I've always found this graphic helpful: https://web.archive.org/web/20211021221111/https://www.4guysfromrolla.com/images/step2.gif
Specifically, the HttpHandlers mentioned in that graphic correspond to this section of the Web.Config file in your .NET web project's root directory:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
The path attribute of that tag can be used to configure only certain directories being handled by a certain class. At that point, IIS will hand off the HTTP request to the appropriate class, with the proper context and thread etc. My guess is that if you are running IIS with multiple frameworks, each has a distinct path associated with its add-handler tag.
Additionally, IIS has its own default settings for what file extensions are mapped to what handler classes. These can also be modified in the IIS management interface, so it's possible that your super-helpful ops team added that for you there even if it's missing from your web.config. At the end of the day, though, it's a relationship between url-HttpHandler class that determines static-file versus dynamic.
Edit:
There's another set of tags, outlined at this ServerFault answer:
https://serverfault.com/questions/175499/serving-cs-csproj-files-on-iis7-5
That describes a <add fileExtension=".cs" allowed="false" /> tag that operates on the file extension as opposed to a pattern on the entire path. This is what disallows files ending in .cs, and .csproj from being served. Additionally, since you're operating on an installation of IISExpress, you should know that it uses a different configuration file than the standard machine.config. The path for that file is described at this answer:
Where is the IIS Express configuration / metabase file found?
All this gets muddied a little by the notion of self-hosting, aka no IIS. Nancy does this, I believe, and ServiceStack can as well. I have no experience doing that, but the way they handle paths is probably a little different.
Ok so this not a big deal, but it's bugging me and I can't let it go.
So I'm using MVC 5.1 with .NET 4.5.1 and OWIN authentication. So when you create a new MVC 5 project, the following is automatically added to the Web.config to get rid of the forms authentication http module because it is no longer needed when using OWIN middleware:
<system.webServer>
<modules>
<remove name="FormsAuthenticationModule" />
</modules>
</system.webServer>
Now since we are removing the module, that means it was previously added, so here is the entry registering this http module in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config:
<httpModules>
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
</httpModules>
And here is the entry in C:\Windows\System32\inetsrv\config\applicationHost.config for IIS 8.5 that tells my application to use the module:
<system.webServer>
<modules>
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" />
</modules>
</system.webServer>
So what is automatically added to my web config at the application level has a name attribute of "FormsAuthenticationModule" while the entries in the two server level/asp.net level config files use name attribute "FormsAuthentication". So what is going on here? It seems to me that the module won't be removed since the name attribute doesn't match. I would simply think this was a typo, but after searching online, everyone seems to be using "FormsAuthenticationModule" in the application web.config. Was this a recent change in the newer version of asp.net / iis or am I missing something?
You're right -- that's a typo in the template.
A major side effect of this "typo" is it will leave FormsAuthentication on causing loginpath of owin to be ignored and calls to authenticated pages going to /login.aspx
I need to write a HttpHandler that will serve up JavaScript files which are embedded resources in .DLLs in my project. A reference in a view cannot directly see such a resource, so I planned to use a HttpHandler module that would intercept any request with a path /js/[file] , find a matching embedded file and return the script.
The problem is that my HttpHandler code is never called, despite trying lots of different settings in the section of web.config. I'm obviously missing something but with no error messages I cannot see what that is. All I ever get is a 404 from the static file handler.
Q1) Am I missing something obvious?
Q2) Is there a way to get IIS to tell me why it is not calling my handler?
Summary: I am testing on IIS Express (v8) for an ASP.NET MVC 4 application.
I created a simple library that implements IHttpHandler and added a reference to this in my test MVC application, and the following lines in web.config:
<system.webServer>
<validation validateIntegratedModeConfiguration="true" />
<handlers>
<add name="ejs" path="js/*" verb="*" type="EmbeddedJsHandler.EmbeddedJsHandler, EmbeddedJsHandler" preCondition="integratedMode" />
The library is there, but it is never called. Any request with /js/test.js or whatever just results in a 404 error.
So far I've tried lots of different configurations and settings in the handler code. I've tried preCondition, resourceType="Unspecified", modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll"
I've tried paths:
js/*.js
js/*
js/*.*
I've checked the integrated mode settings section (in system.webServer) is being used, and confirmed it is.
I've searched stack overflow for similar cases, and tried many of the possible solutions.. still no joy.
Heck even Jon Skeet has these sort of problems!
Why isn't my IHttpHandler being called?
Finally figured it out by accident - it was a missing routes.IgnoreRoute() in the RouteConfig.cs file - the MVC routing engine wasn't configured to ignore this path, so was passing it to the static file handler.
Doh!
Check this:
How to: Register HTTP Handlers:
To register an HTTP handler for IIS 7.0 running in Integrated Mode:
Compile the HTTP handler class and copy the resulting assembly to the Bin folder under the application's root folder.
In the application's Web.config file, create a handlers element in the system.webServer section.
The following example shows how to register an HTTP handler that responds to requests for the SampleHandler.new resource. The handler is defined as the class SampleHandler in the assembly SampleHandlerAssembly.
<configuration>
<system.webServer>
<handlers>
<add name="SampleHandler" verb="*"
path="SampleHandler.new"
type="SampleHandler, SampleHandlerAssembly"
resourceType="Unspecified" />
</handlers>
</system.webServer>
</configuration>
Note: The resourceType attribute performs the same function as the Verify file exists option in IIS manager for IIS 6.0.
For IIS 7.0 running in Integrated mode, only the registration in the handlers element is required.
I cannot tell you directly why your handler isn't working, but I will give you an example of a handler we use and works for us:
<system.webServer>
<handlers>
<add name="JS handler" path="*.js" verb="*" type="Handlers.Minifiers.JSMinify" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
We also have this segment, which is at least necessary for running in Cassini
<system.web>
<httpHandlers>
<add verb="*" path="*.js" type="Handlers.Minifiers.JSMinify" validate="false"/>
</httpHandlers>
</system.web>
If this doesn't help, have tou tried using path="/js/*"?
I am experimenting with the integrated authentication mode for static content in IIS7. I followed the instructions in this article: https://web.archive.org/web/20210612113955/https://aspnet.4guysfromrolla.com/articles/122408-1.aspx
It is working fine if I allow/deny access by login status (like in the article). However I want to allow/deny access based on roles (using the ASP.NET built in Roles Provider). When I put an allow rule for the role "Admin" in the web.config and deny rule for all other users I am not able to access the static files even when I login as an admin. The same folder contains non-static content (aspx pages) that are accessed just fine based on the Role Provider information.
Any ideas?
Try adding the following to your <system.webServer> <modules> block:
<configuration>
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
</modules>
</system.webServer>
</configuration>
The RoleManager bit is key, and it's not included in any of the online examples that I could find. Without that, the user's role membership isn't initialized for static content, so role-based authorization will always fail.
(Disclaimer: I've pieced this together myself based on my limited understanding of IIS, but it seems to work.)
Edit (in response to your comment): Sorry, I don't know much about how RoleManager depends on other modules. You can view the default IIS configuration by looking at c:\Windows\System32\inetsrv\config\applicationHost.config (at least, that's the past on my Windows Vista machine) to see the order in which modules are loaded (note the use of managedHandler by default to restrict RoleManager to non-static content), and MSDN covers RoleManagerModule along with the rest of the modules in the System.Web.Security namespace, so you could probably find what you need there.
I would say the most likely culprit is that the static files are not being processed by ASP.NET but being left up to IIS.
Does it work if you add a wildcard script mapping?