Have a rather large problem. About two weeks ago I noticed that alert based validation (ValidationSummary) stopped working on my website. Upon further review, WebResource.axd is coming back blank. It's not throwing an error, just blank.
I've tried tracing the request via Fiddler and Firebug, and the response is 200 at first. Subsequent cached requests (same page) return 304 (as I would expect).
I've checked IIS configuration, web.config, installed updates, Global.asax, httpHandlers etc... to try to find out what happened or why it's failing.
I've been troubleshooting this issue for two days now and am running out of options. Does anyone have any idea what the cause of this could be? Any help is greatly appreciated.
This appears to be a tricky issue, can you check and answer the following two questions:
By any chance is debugging enabled on your deployed site.
Was the deployed website build properly in release mode?
I found the issue. Whilst installing John Papa's Hot Towel MVC project into a web forms/MVC hybrid, the routing config does not contain an IgnoreRoute instruction for AXD paths.
This means routing picks up the request ahead of the HttpHandler, and returns a 200 even when no controller exists for the given route pattern - hence a 200 response with an empty body.
I'll pull the bounty but I will upvote Shashank's answer.
Related
I am setting up a web api for the first time and I have another project for reference. It is a .NET framework project that will have a React frontend. I am running it using Visual Studio and IIS Express.
I have no build errors when I start the api project. It has swagger added so I can test database calls, so I know the api itself is working. But I am missing adding something as I am looking to add more security to it.
I am trying to verify authentication and I want to use integrated Windows authentication. When I set a break point, the user in the HttpContext.Current is never set and is never authenticated, so I can't add any authorization filters.
I went back to just the basic empty api project that has the frontend web pages removed to see if I removed something and it shows the same issue. So I either removed it again or I am actually missing adding something.
I am not sure where to look for what is missing, so any pointers would be appreciated.
The left browser is what I am expecting and the right browser is what I am seeing.
I don't need the directory browse turned on, so seeing a 403.14 - Forbidden is fine. But I am clearly missing something to get to that point. Is there a better way to figure out which resource/dependency is causing this error?
I can also see the working version requested url is what I am expecting, but the other is just a /.
Is there a way to resolve that if this is the error?
I can add code snippets if needed, but I haven't yet as I am not sure where the issue is.
I ended up finding the answer using blank test web apis to see what I may have left in that wasn't needed. The project was set up using this option:
After removing the views, etc., to make it strictly an api project. I started removing references (and clearing the associated errors) and seeing what happened with the build after each change.
Under the App_Start folder, there were some additional files that weren't present in the project I had for comparison - FilterConfig, and RouteConfig - which were also called in the Global.asax.
I removed the call in Global.asax for all three and I was able to see the expected http error page.
I dont have enough reputation for a comment, but you got 404 error, which, as you know, means there is nothing on that url. So check the route config and startup.cs Edit: I am on the phone so I didnt saw you already solved it. Good :)
I have just started a MVC project and I faced with a very strange behavior.
When I run it it displays me some empty Home/Index
But when I go to firebug I see tens of very strange and endless requests, like this one:
GET http:// localhost :58567/3a5679dd22ba46d1993...%00101+Firefox%2F33.0&tid=7&_=1417193472430
And such the requests go one after another one and don't stop, although I don't trigger any action.
I don't understand where they come from. My app does not send any request and previously I've never faced with such the behavior. In my previous experience firebug showed me only the requests I made.
Please advise.
These requests come from the "Browser Link" feature in Visual Studio, they're not something you'll have manually added. There's more detail on the feature at http://www.asp.net/visual-studio/overview/2013/using-browser-link , including how to disable it if you don't need it.
I have several IIS sites running on my local machine running IIS 8. 3 of the sites work perfectly fine, the 4th returns a 404.0 Error:
"HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly. "
I have tried everything I can think of but nothing will work. To save people some time I will list some of the things I tried:
Adding UrlRoutingModule to my Web.config
Removing the WebDAVModule
Adding ExtentionlessURLHandlers
I have also confirmed that the path is correct and the site is in the correct application pool. I am running out of things to try everything I see on the web seems to say one of these things I tried will fixed it but it hasn't. My IIS local web server seems to be installed corrected as my other sites work fine, please help!!
After a very frustrating day I solved my issue, and it was really due to my last of MVC routing knowledge. I was attempting to navigate to "localhost/example" which had not controller routing associated with it because I had no home controller. I either needed to map a home controller to it, change the default controller to map to one of my existing controllers, or the easiest fix was to navigate to "localhost/example/controllername" where "controllername" is the name of the controller that I wanted to start at. I hope this can save someone else hours of time.
I added WebResource.axd (empty file) manually in production environment (IIS7 and Windows Server 2008) after chrome and firefox was giving error 404 for WebResource.axd. And now it is working fine, even with parameters. I am not sure why ASP.NET generating this script in final render result (no problem with VS2008), but now it is working. I want to know, is there any security implications other than what normally associated with WebResource.axd as it is in root directory?
Thanks
I also had this issue recently, after a code change WebResource.axd stopped working for my site. Basically, it exposes dynamic resources over http. For a longer explanation visit:
Just where is webresource.axd?
Typically, what happens is that one of the dynamic resources being requested has failed, but the resource name is encrypted. This blog post will help you decrypt the name, use it and the query string of your failing webresource.axd?___ request to figure out where the error is coming from.
Telerik webresource troubleshooting
we were all recently alerted by scottgu with this security vulnerability. http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
I'm wondering, since I've been redirecting errors via Global.asax on the Application_Error event, I was wondering if that can suffice the fix for this issue or do I still need to place a setting on the web.config?
The problem is that (according MS) you need to respond ALWAYS in the same way, no matter the specific error you have.
You'd need to redirect the user to the same page on errors 404 and 500. That's why the easiest way would be using the web.config setting.
They say that this would be temporary and you could revert it once they release a patch for this.
This is the Scott answer to a similar question:
I would recommend temporarily updating the module to always redirect to the search page. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.
Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now I'd recommend not differentiating between 404s and 500s to clients.