Ive added custom error pages to my project, and referenced them in the web.config like so:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/Errors/500.aspx">
<error statusCode="404" redirect="~/Errors/404.aspx" />
<error statusCode="500" redirect="~/Errors/500.aspx" />
</customErrors>
When I browse to a page that does not exist I see the 404 page rendered as expected.
However, I now have a bug in the following POST controller method:
CheckRenewalEligibility(string uprn);
When I click the button which invokes this, nothing happens. When I open dev tools in chrome I can see:
And then when I click on the red highlighted CheckRenewalEligibility to see the Preview, it displays my custom error page.
My question is, why is this not being rendered in the front end when a 500 error is clearly occurring, why is it just doing nothing.
note I have an aspx and html version of both custom error pages sat in the Errors path.
The issue you are having is because you do your request via AJAX. In these cases in server side errors, error pages are rendered, but never displayed to a user - that is the nature of AJAX.
Since you have not indicated the way you do your AJAX execution, I'll presume you are using popular jQuery. For ajax requests via jQuery have a look on this answer - explains how to capture server-side errors.
Related
Asp.Net MVC application
When user tries to submit HTML or JavaScript code in query string of action method , getting Internal server error(500) with below exception..
A potentially dangerous Request.QueryString value was detected from the client (userid="'"-->..script..").
I have enabled the custom error mode so that end user is redirecting the custom error page for any XSS attacks.
But when I run NETSPARKER ENTERPRISE SCAN against action method with javascript code in query string , report coming as Internal server error - The server responded with an HTTP status 500.
What is the best practice to handle this internal server issue.
Suggestion: Custom Error handler
I am not sure about best practice, but what I use is <customErrors> in the web.config to redirect the user to a "nice" web page. The page it redirects to can be a plain HTML, ASPX etc. The nice thing is that you can setup a default custom error page, plus individual ones based on HTTP Status Code.
Follows is a snippet from my web.config for a default error code handler, plus one for HTTP 500 (Internal Server Error) which is what you are getting for the A potentially dangerous Request.QueryString value was detected error:
<customErrors mode="On" redirectMode="ResponseRedirect" defaultRedirect="~/dangitall.html">
<error statusCode="500" redirect="~/dangitall500.html" />
</customErrors>
dangitall.html is a standard HTML page for all error. Its overridden by dangitall500.html which will display for HTTP 500 errors. The contents of these HTML pages can be whatever you want: warn the user, abuse the user etc :)
Follows is a link to the Microsoft tech article regarding custom errors and all of the possible attribute settings etc:
https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.customerror?view=netframework-4.8
The title says it all. There's actually a ton of information on how to do this and I'm very close. I've read several things on google as well as the following stackoverflow posts:
How can I properly handle 404 in ASP.NET MVC?
How can I properly handle 404 in ASP.NET MVC?
Custom error pages on asp.net MVC3
http://blog.davebouwman.com/2011/04/21/custom-404-pages-for-asp-net-mvc-3/
I've got 404's working at the action level. And I'm using the *.aspx suffix on my controllers. If you have a url like
"http://blahblah/AppName/idontexist.aspx"
The custom Error controller is loaded. My issue comes down to controller's that don't have the .aspx and also do not exist. This yields the typical IIS Server 404 html page, which I don't want. Another kink in the works is that I can't really change the IIS configuration itself. I have to handle this via the code/web.config/global.asax (or some other part of the project I haven't thought of).
Here are my web.config entries (this is the root web.config, not the view one):
<httpErrors defaultPath="/Error.aspx/HttpError" errorMode="Custom" existingResponse="Replace" defaultResponseMode="ExecuteURL">
<remove statusCode="500" subStatusCode="-1" />
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="500" path="/Error.aspx/HttpError" responseMode="ExecuteURL" />
<error statusCode="404" path="/Error.aspx/NotFound" responseMode="ExecuteURL" />
</httpErrors>
<customErrors mode="On" defaultRedirect="~/Error.aspx/HttpError">
<error redirect="~/Error.aspx/NotFound" statusCode="404" />
</customErrors>
And here are my routes in global.asax:
routes.MapRoute(
"Default", // Route name
"{controller}.aspx/{action}/{id}", // URL with parameters
new { controller = "StartController", action = "StartAction", id = UrlParameter.Optional } // Parameter defaults
);
routes.MapRoute(
"NotFoundController", // Route name
"{controller}.aspx", // URL with parameters
new { controller = "Error", action = "NotFound" } // Parameter defaults
);
routes.MapRoute(
"NotFoundController2", // Route name
"{controller}", // URL with parameters
new { controller = "Error", action = "NotFound" } // Parameter defaults
);
routes.MapRoute(
"Root", // Route name
"", // URL with parameters
new { controller = "StartController", action = "StartAction", id = UrlParameter.Optional } // Parameter defaults
);
I also think that one snag with using routes to catch these is that I lose the 404 status code; however, because the route points to an action specifically designed for this purpose, I suppose that point is moot.
Anyhow, any thoughts, suggestions, or criticisms would be welcomed. I'm very close here. Thanks!
EDIT 1
I've still been researching this. Is there a way I can define a custom route constraint that will redirect to the Error Controller if the text ".aspx" is not found in the url?
EDIT 2
Doesn't look like that's how constraints are intended to be used. I also tried implementing the
protected void Application_Error()
{
}
method per the implementation at http://blog.davebouwman.com/2011/04/21/custom-404-pages-for-asp-net-mvc-3/, but when I don't specify .aspx for the controller, it looks like the application never gets a chance to throw an error. It looks like that is handled by IIS before my app can even respond to it.
If I could make IIS changes, preferably to just this application's virtual directory entry, would that allow for a more viable solution to this?
If there was just somewhere I could grab the url, search for .aspx, and if it's not found throw a 404 not found, but redirect to the application level 404 page instead of the IIS default, that would be pretty close to ideal.
Thoughts?
EDIT 3
I'm of the opinion that handling this scenario is just not possible unless your application is the root site for the IIS server and not a virtual directory. I noticed that, within IIS 6.0, you can tweak the default IIS error pages. Not only that, you can replace certain cases with a URL. I've tried doing this with a virtual directory site but the default IIS 404 Not found page displays.
So it amounts to: you can handle this on IIS 6 if you have a stupid amount of control over your setup and the site you're doing this for is the root site.
Not very applicable in real world scenarios I imagine.
I don't think this is possible without being able to make changes to IIS. With IIS 6, requests don't enter the ASP.Net realm unless they are mapped to the ASP.Net ISAPI handler (aspnet_isapi.dll). For normal ASP.Net extensions, the mapping is already setup in IIS6 when .Net is installed (.ashx, .aspx, etc). This is why your 404 for a controller that doesn't exist gets the normal IIS 404 page. IIS is looking for a folder that doesn't exist on disk.
In order to get your 404 page handlers to work as expected (this is assuming you COULD make changes to IIS), you'll need to setup what is called a wilcard mapping. This sends all requests to the ASP.Net ISAPI. IIS also needs to be instructed to bypass the check for a physical file, since none will exist in this case. There's a checkbox for that option. I no longer have IIS 6 in front of me, but Option 1 on this site walks you through it:
http://blog.stevensanderson.com/2008/07/04/options-for-deploying-aspnet-mvc-to-iis-6/
I have done this before, it does work. There are some tradeoffs from sending everything to the .Net ISAPI. All static files will be handled by ASP.Net (even images) instead of IIS directly, so just be aware of the implications there.
Hope this helps
I used a new domain. When I set only html pages than site running correct.
But when I use web.config and aspx page then site give an error.
Error is : HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.
You may first check whether web.config is well-formed, next you may change customError's mode to off like the following snippet
<customErrors mode="off" />
The above would reveal any error details related to your aspx or code-behind.
So I have a web page written in C# for ASP.NET and in some cases it returns a custom error.
For example, at one point it can be like:
Response.StatusCode = 400;
Response.Status = "A long custom error message here.";
Response.Write(Resonse.Status);
and when I open this up locally (through http://mymachinename/foo/bar.aspx) I see my custom error message. When I deploy it to a remote server I just see my custom error message overwritten with the text "Bad Request" (that's all). It must be some configuration, but I can't find it.
Check to see if you have the httpErrors attribute defined in your web.config.
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
Servers can have their own configuration files with error codes like you mentioned. For example, editing the .htaccess file on an apache server will allow you to link your own error pages to the exceptions, or you can just write in the markup yourself to save some time.
Update
You can also do
Response.TrySkipIisCustomErrors
if you are using IIS that is.
Additional Info
http://blogs.iis.net/ksingla/archive/2008/02/18/what-to-expect-from-iis7-custom-error-module.aspx
Those solutions provided by other guys are perfectly valid, But I think you can control it from you IIS Manager too, if there is a defined error page with code 400, Open your IIS Manager, go to .Net Error Pages, look for error code 400 click on edit feature setting on the right panel then select Off in the opened Edit Error Page Setting window.
When I try and run a forum page:
System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client
In my web.config I have:
<pages validateRequest="false" smartNavigation="false">
And on the actual page I also have:
<%# Page Language="C#" AutoEventWireup="true" ValidateRequest="false" MasterPageFile="~/MasterPages/Main.master" %>
But it keeps throwing this error!
Edit
I fixed it with:
<httpRuntime requestValidationMode="2.0" />
But what's that do and why does it work?
This error occurs because something in the submitted form, or in the querystring, looked dangerous to the validation in ASP.NET.
By adding
<httpRuntime requestValidationMode="2.0" />
you are relaxing the validation that is applied back to the standards of ASP.NET 2.
I would say you are far better off trying to work out exactly what it objects to in your form/querystring than just relaxing the validation. This tightened validation is there to protect you and your users, and shouldn't be relaxed lightly.
I have recently hit this on a project I am working on when we upgraded to ASP.NET MVC3 (from version 2). In our case it actually highlighted an issue whereby we were urlencoding our querystring when we didn't mean to (i.e. the entire quertstring including the question mark and the ampersands was all getting url encoded when it shouldn't be).
Whatever your reason, look for the root cause rather than relax the validation if it is at all possible.
There was probably markup in the submitted text. http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes
The request validation feature in
ASP.NET provides a certain level of
default protection against cross-site
scripting (XSS) attacks. In previous
versions of ASP.NET, request
validation was enabled by default.
However, it applied only to ASP.NET
pages (.aspx files and their class
files) and only when those pages were
executing.
In ASP.NET 4, by default, request
validation is enabled for all
requests, because it is enabled before
the BeginRequest phase of an HTTP
request. As a result, request
validation applies to requests for all
ASP.NET resources, not just .aspx page
requests. This includes requests such
as Web service calls and custom HTTP
handlers. Request validation is also
active when custom HTTP modules are
reading the contents of an HTTP
request.
As a result, request validation errors
might now occur for requests that
previously did not trigger errors. To
revert to the behavior of the ASP.NET
2.0 request validation feature, add the following setting in the
Web.config file:
<httpRuntime requestValidationMode="2.0" />