This is obviously a security issue and probably do not want to change this, but it would be nice to handle the error. Any ideas?
I see that stackoverflow is not immune:
https://stackoverflow.com/questions/tagged/web.config
They seem to have changed the tag to web-config to fix the problem but you still get a very nasty error message when you search for [web.config]
I believe this has been addressed in ASP.NET 4 with the addition of a new web.config setting
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
</system.web>
</configuration>
Phil Haack has more details.
In IIS 7, this can be found under Request Filtering. Other extensions that are filtered by default include:
.asax
.ascx
.master
.cs
.csproj
etc.
It's not a bug BTW, because the request gets filtered before ASP.NET gets a chance to process it. In other words, you could remove the request filter and have IIS process the extension if you want to, but make sure the extension is handled by ASP.NET and not the static file handler.
Edit: Maybe the answer for SO would be to change it so that when tags have a .XXX extension like web.config, they change to web-config or something else that IIS doesn't filter. This probably also would be a good topic on https://meta.stackoverflow.com/
Related
So I am having this issue of getting CSS files applied through the masterpage. I had another question: Can't get CSS loaded in Master page that helped me to apply the link tag correctly (or different options).
This is confirmed in Firebug where the call is coming back 302 found, but the styles are not being applied.
This question lead to another contributor pointing out possible access issues to the controller/content in my Web.config. Thus the reason for this question separate "Security" related question.
I have went through a number of full MVC app tutorials such as NerdDinner (v.1, v.2) and Pro MVC 2's not to mentioned a good bit of reading material in my pursuit to learn ASP.NET MVC - and I have not come across any details on access to sources such as /Content to anonymous users just to load css files. Nor have I read anything that MVC takes the approach that it is entirely locked down and you must open specific areas to specific roles/users/everyone OR open it all up for everyone.
So I still have the problem of not being able to get CSS rules applied even though it shows that the .css file is being found (302). But another issue is that I am seeing a second call to load the file in the console:
localurl.com/Account/Logon?ReturnURL=%2Content%2AdminViews.css
But errors with a 500.
Now I have commented out the logon URL line in my web.config "Authentication" section, and there is no route that I can see in my route dictionary.
Any thoughts on both of these related issues?
UPDATE
I found that the problem with why the redirection to the
localurl.com/login.aspx?returnurl=content/adminview.css
was that theforms authentication (in IIS) was enabled with the properties set to "Login.aspx". Changing this generated an ACL rights (yellow screen of death) when accessing the file directly
localurl.com/contents/adminview.css
I found adding users to the content directory (i.e. IUSR account) would rectify this issue.
So I now need to find what the proper way to set security. What account I should use ...etc. I did already have the IUSR_ComputerName already given access, which my understanding is the default IIS anonymous user account. So why this wouldn't be enough to access resources in the ~/contents/ directory is beyond me.
You could allow access to these resources using web.config.
<location path="Content">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
I have an IIS7.5 web-site, on Windows Server 2008, with an ASP.NET MVC2 web-site deployed to it. The website was built in Visual Studio 2008, targeting .NET 3.5, and IIS 5.1 has been successfully configured to run it as well, for local testing.
However, whenever I try and navigate to a page running in IIS7, I get a 404 error.
I have checked the following things:
There is no corresponding 404 log entry in IIS logs.
Actually, there are 404 entries in the IIS log.
The application pool for the web-site is set to use the Integrated pipeline.
The "customErrors" mode is set to off.
.NET 3.5 SP1 is installed
ASP.NET MVC 2 is installed
I've used MVC Diagnostics to confirm all MVC DLLs are being found.
ASP.NET is enabled in IIS, which we've demonstrated by running the MVC Diagnostics page.
KB 2023146 did highlight that HTTP Redirection was off, so we've turned it on, but no joy.
EDIT
Ok, so we've installed the world's simplest MVC application (the one which is created when you create a new MVC2 project in Visual Studio), and we are still getting 404s on any page we try and access - e.g.
<my_server>/Home/About will generate a 404.
Any ideas will be greatly appreciated!
This is quite often caused by the following missing from the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
Do you have a problem with just 1 page or the whole site is not working?
A) 1 page
You can use RouteDebugger to verify if the route is matched correctly
B) Whole site
I assume you're using Windows Server - check if ASP.NET is enabled in IIS - it's disabled by default, I believe.
You can use MvcDiagnostics page to check if all dlls are deployed properly.
Are you running in IIS7 integrated mode? Classic mode of IIS7 does not automatically map extensionless URLs to ASP.NET (much like IIS6)
Make sure your Web.config tag is configured correctly.
We finally nailed this issue by exporting the IIS configuration of a working server, and comparing it to ours.
It was a really obscure setting which had been changed from the default.
IIS ROOT → request Filtering → Filename Extensions Tab → Edit Feature Settings → Allow unlisted file name extensions
This should be ticked.
This can be set at the IIS level, or the site-level.
Glad that fixed your problem. Others researching this issue should take note of the extensionless URL hotfix: http://support.microsoft.com/kb/980368
If none of the other solutions here solved your issue, check that you have the
Global.asax
file in your website. This solved the issue for me.
Checkout if KB 2023146 applies to your scenario. Also try requesting directly a controller action: /yoursitename/home/index
Apparently this can have many different causes.
For us, the problem was that the DNS entry was configured for two IP addresses, but the IIS configuration would only listen to one of them. So we got unpredictable results, sometimes it would work, sometimes a few files (css, etc) would not load, and sometimes the whole page would not load.
For me it was all about installing .NET Framework 4.6.1 on the server (my app was targeting that version)
You'll also get this if your bindings aren't correct. If you don't have www or a subdomain it'll return a 404.
I had this problem when running my MVC4 site with an app pool set to ASP.NET 4.0 and the Classic pipeline, even though the extension handlers were set in my web.config and were showing correctly in IIS. The site worked in Integrated Pipeline so I knew it was a configuration issue, but I couldn't nail it down. I finally found that ASP.NET 4 was disabled for the server in the ISAPI and CGI Restrictions settings. I enabled ASP.NET 4.0 and it worked.
In addition to checking if you're running in integrated pipeline mode, make sure your application pool is set to use .NET! I recently ran into this problem, and when I went in to check the app pool settings, I found that somehow it had been set to "No Managed Code." Whoops!
My Hosting company fixed this for me by doing this (I removed the original password value of course).
<system.webServer>
<security>
<authentication>
<anonymousAuthentication password="<password>" />
</authentication>
</security>
</system.webServer>
Typically I encounter this issue when there is a Routing problem. I compare a working vs non-working to resolve it.
Today however I accidentially created a Virtual Directory in IIS.
It has to be an Application, right click on the Virtual Directory (with a folder icon) -> Convert to Application:
Don't use runAllManagedModulesForAllRequests. You want to let IIS handle resources such as images.
<system.webServer> <!-- Rather do NOT use this -->
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Instead add the MVC routing module
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>
My ASP.NET MVC application is within a folder called Stuff within IIS 6.0 webroot folder. So I access my pages as http://localhost/Stuff/Posts. I had EMLAH working while I was using the in-built webserver of Visual Studio. Now when I access http://localhost/Stuff/elmah.axd, I get resource not found error. Can anyone point my mistake here! Here is config file entry,
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/> //Handler
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah"/> //Module
Working with IIS7 I found I needed both sections of the web.config populated (system.web AND system.webServer) - see Elmah not working with asp.net site.
Perhaps this is related.
Have you added an ignore *.axd routes in global.asax?
For Elmah, we need to differentiate between two things:
First the http modules doing all the work of error logging, emailing...etc.
Second, the http handlers, displaying the error log page and other pages (rss...etc.)
I was having the same problem of 404 resource not found because I have a weird setup!
on my development machine, (windows 7, iis 7 ) elmah was working like a charm because the application pool was working in the integrated pipeline mode. In the production machine, however, the application was using the managed pipeline and I tried all my best to make elmah work but it was all useless...
I then got the idea of displaying the UI (error log page, rss, error detail,...) using regular aspx pages.
I downloaded the source code, made some changes (sorry Atif, I was forced to do this because I needed the quickest solution) and then in my application , I created a folder under which I created regular aspx pages which inherits from Elmah defined pages.
The page only contains one line (ex: for the detail page: <%# Page Language="C#" Inherits ="Elmah.ErrorDetailPage"%>)
Now, I was able to run Elmah regardless of IIS 6/7 and it is working like a charm.. and It saved me from a big headache of correctly configuring http handlers and troubleshooting its work! additionally, configuring security is much simpler!
I don't know if the community is interested in this solution (If so, I am ready to post my full changes).
Hope that this gives you an idea on how to solve the problem in an alternative way (and if you need the modified dll with complete instructions on how to use it, just tell me!)
In the application pool settings in IIS set Managed Pipelin Mode to Classic if you don't want to change code or the web.config file. Your axd.s will then work as before.
Can you post the rest of your web.config?
Or, if you're comfortable enough, can you just ensure that the httpHandlers and httpModules (NOT handlers and modules) sections are filled in properly in the web.config?
I am having the standard issue timeout exception in my production environment whereby, after 90 seconds, the thread will be killed. For the vast majority of my site this isn't a problem.
However, my sitemap generator is an exception to the rule.
Because it relies on the routes created in the application, I have chosen to create it inside the project, as it loads all routes in from the app, and then, effectively uses a customised Html.Action to generate each route.
Because it takes a fair while to create the entire sitemap (5 minutes at last count), I get a YSOD before it has a chance to complete. Now, in webforms, I'd just create a web.config in the directory, and a nice little handler for that page using the location element:
<configuration>
<location path="sitemapgenerator">
<system.web>
<httpRuntime executionTimeout="600" /><!-- Ten minutes -->
</system.web>
</location>
</configuration>
Without actually creating this config file, I'm convinced that, not only will this not work, but it's also pretty bad practice in MVC anyway, because it then restricts the naming of the sitemap generator to whatever is set in the config file, and not just the routes.
I could just ensure that the routes and the config file stay up-to-date if I need to change it, but this just seems messy in MVC.
Can anyone give me any suggestions about this, and whether this web.config method will work out?
Many thanks in advance.
Update: I've done a test on this, and no, it does not work, so I have no fallback solution either. :)
Have you tried setting the scriptTimeout property in the initialization of the site map generator?
Server.ScriptTimeout = 600;
In our ASP.NET MVC application, we've noticed that we cannot have The Forbidden DOS File Names—COM1 through COM9, LPT1 through LPT9, CON, AUX, PRN, and NUL—anywhere in our routes. They inevitably result in IIS telling us the file cannot be found, even when we set routing not to check for the existence of files first. How can we work around this?
This has been addressed in ASP.NET 4. http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx
You can apply a setting in web.config that relaxes this restriction.
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
<!-- ... your other settings ... -->
</system.web>
</configuration>
Hope that helps.
Since asking the question, I've found that the bug is in ASP.NET proper, not IIS or ASP.NET MVC, meaning that there's no way to work around it. The only solution is to manually forbid URLs matching these names and these names followed by a period and random characters.
For a similar reason, there can't be a web.config tag in StackOverflow.
http://stackoverflow.uservoice.com/pages/1722-general/suggestions/98871-web-config-tag-404-error
for another similar reason you can't have urls with a dot and a slash
Semantic urls with dots in .net