The MVC project has a Startup.cs file in its root. When i run the project it throws
HTTP Error 404.7 - `Not Found. The request filtering module is configured to deny the file extension
web.config
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.webServer>
<defaultDocument>
<files>
<add value="Startup.cs" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
I added the following lines of config inside system.webserver tag - but there is no change:
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<remove fileExtension="." />
<add fileExtension="." allowed="true" />
</fileExtensions>
</requestFiltering>
</security>
You do not need to add any defaultDocuments, and should not use cs files there.
If you are using the default route, it is sufficient to add a Home controller with a Index action, which will be called by default. You can adapt the default route to use another controller/action.
I have a small, simple ASP.Net 4.5.2 Web App for which access is restricted by IIS Manager Users. The parent site is public (Allow Anon / All Users) and the app has all authentication disabled and the IIS User added at server level, and under IIS Authorization Rules as seen in the config below. This works perfectly on IIS 8.5, but the login fails on 7.5 with 401 Unauthorized.
I've combed through the role features and site and server and app settings and I can't find a difference between the two, other than 7.5 on Win Server 2008 vs. 8.5 on Win Server 2012-R2. Both have IIS Management Service running with Windows and IIS Manager Users selected, and the Enable remote connections unchecked (only using it for app access, not administration). Both are using the ASP.Net 4.0 App pool under Network Service, who has full rights to the web folder structures on both servers.
Ideas on what to look for would be appreciated.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<compilation strict="false" explicit="true" debug="false" targetFramework="4.5.2" />
<customErrors mode="Off" />
<httpRuntime targetFramework="4.5.2" />
<webServices>
<protocols>
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
</system.web>
<system.webServer>
<handlers>
<add verb="GET,POST" name="About" type="MyApp.About" path="About" />
</handlers>
<modules>
<!-- Replaces Global.asax -->
<add name="AppModule" type="MyApp.AppModule" />
<!-- Required for IIS Manager Users to browse the site -->
<add name="WebManagementBasicAuthentication" type="Microsoft.Web.Management.Server.WebManagementBasicAuthenticationModule, Microsoft.Web.Management, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</modules>
<defaultDocument enabled="false">
<files>
<clear />
</files>
</defaultDocument>
<directoryBrowse enabled="false" />
<security>
<authorization>
<clear />
<remove users="*" />
<add accessType="Allow" users="IIS.Manager.Username.Here" />
</authorization>
</security>
</system.webServer>
</configuration>
Finally found that on the newly spun up 2008 / IIS 7.5 server Network Service didn't have Read permissions to c:\Windows\System32\inetsrv\.
my web.config is as
<?xml version="1.0" encoding="utf-8"?>
<!--
Web.config file for first.
The settings that can be used in this file are documented at
http://www.mono-project.com/Config_system.web and
http://msdn2.microsoft.com/en-us/library/b5ysx397.aspx
-->
<configuration>
<system.web>
<compilation defaultLanguage="C#" debug="true">
<assemblies>
<add assembly="System.Net, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add assembly="System.Data.Services.Client, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
<customErrors mode="Off"/>
<authentication mode="None">
</authentication>
<authorization>
<allow users="*" />
</authorization>
<httpHandlers>
</httpHandlers>
<trace enabled="true" localOnly="true" pageOutput="false" requestLimit="10" traceMode="SortByTime" />
<sessionState mode="InProc" cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<pages>
</pages>
</system.web>
<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>
</system.webServer>
</configuration>
when I run it
it gives me an error like \
Application Exception
Runtime Error
A runtime error has occurred
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed (for security reasons).
Details: To enable the details of this specific error message to be viewable, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
A quick search using Google reveals:
CustomErrors mode="Off"
Basically you need to adjust a few other settings
I made a tweak to an aspx.vb file on a test server, just a small change to a custom error message being written in the code, by making a copy of the file, changing the text and replacing the file on the server. However, the change will not reflect when I go back to the page from the browser.
I was thinking it had something to do with the file not being compiled. However, it seems as if aspx.vb file should be compiled dynamically. Is there a setting that ensures that this happens? This is a copy of the web.config file:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation debug="true" strict="true" explicit="true" />
<authentication mode="Windows" />
<identity impersonate="true" />
<customErrors mode="On" />
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<defaultDocument>
<files>
<add value="MyIdeaSSO.aspx" />
</files>
</defaultDocument>
<directoryBrowse enabled="true" />
</system.webServer>
<location path="MyIdeaSSO.aspx">
<system.webServer>
<defaultDocument enabled="true">
<files>
<add value="MyIdeaSSO.aspx" />
</files>
</defaultDocument>
</system.webServer>
</location>
</configuration>
I guess the main thing i want to know is if changes to an aspx.vb page already on a server, should need anything else for it to work. Thanks.
You will need to compile the application, .vb file update will be contained in the application's dll.
I have a website running on a IIS 7.5 server with ASP.NET 4.0 on a shared host, but in full trust.
The site is a basic "file browser" that allows the visitors to login and have a list of files available to them displayed, and, obviously, download the files. The static files (mostly pdf files) are located in a sub folder on the site called data, e.g. http://example.com/data/...
The site uses ASP.NET form authentication.
My question is: How do I get the ASP.NET engine to handle the requests for the static files in the data folder, so that request for files are authenticated by ASP.NET, and users are not able to deep link to a file and grab files they are not allowed to have?
If you application pool is running in Integrated mode then you can do the following.
Add the following to your top level web.config.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" 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" />
</modules>
</system.webServer>
Now you can use the standard ASP.NET permissions in your web.config to force forms authentication for all files in the directory.
<system.web>
<authorization>
<deny users="?" />
</authorization>
<authentication mode="Forms" />
</system.web>
I had the same problem with getting roles to authenticate. Through trial and error I finally got it to work with a small edit to #Joel Cunningham's code:
<modules runAllManagedModulesForAllRequests="true" >
I used these two sites as references: http://forums.iis.net/t/1177964.aspx and http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/
This is an old thread, but I happened on it and ran into the same problem as Egil. Here is the version of Joel's fix that includes roles:
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
Addendum:
As #eych noted the accepted answer also blocks access to the ~/Content folder (or wherever you have your CSS), and ~/Scripts, and so on.
If you want to allow exceptions -- i.e. allow certain files/folders to be accessible by unauthenticated users -- you can do that by means of the location element. Add the following to web.config:
<location path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Update:
An alternative solution is to is to leave access on by default -- which will allow access to your CSS / JavaScript / etc. -- and apply the "lock" (only) to the folder where the static content is stored:
<location path="data">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Caveat: in our case (an MVC site) we needed to decorate all our controller actions (except login) with [AuthorizeAttribute]. Which is a good idea anyway, but had previously not been necessary (because previously any unauthorized request was redirected to the login page).
I wanted to know why it would be required to re-add modules (with default options) that are added by default for the Integrated Pipeline, so I dug a little deeper.
You need to remove and re-add the modules because, by default, the modules aren't added with the default options. They have a precondition added for backwards compatibility to run only for content handled by a registered ASP.NET handler (e.g., .aspx pages).
The default looks like this:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
By removing the modules and re-adding them without a precondition, those individual modules run for every request (including your static content). It is more granular than enabling runAllManagedModulesForAllRequests.
You can read about it in a couple articles from when the Integrated Pipeline was introduced with IIS 7:
ASP.NET Integration with IIS 7
How to Take Advantage of the IIS 7.0 Integrated Pipeline
Note that there is a typo or the module name in the second article (and #John's answer) was changed from FormsAuthenticationModule to FormsAuthentication at some point.
The set of working modules in IIS 7.5 thru 8.5 looks like this for me:
<system.webServer>
<modules>
<!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>
If you application pool is running in Classic mode, you can do the following. You will have to repeat these steps for each file extension you'd like to handle, but I'm using .html here.
First, add a page build provider to the Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
</buildProviders>
</compilation>
</system.web>
</configuration>
Then add a page handler factory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpHandlers>
<add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
</httpHandlers>
</system.web>
</configuration>
Then add a page handler:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
</handlers>
</system.webServer>
</configuration>
This worked for me. (Credit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)