Describes how to set Asp.net web. config customErrors,

Describes how to set Asp.net web. config customErrors,

Summary

<CustomErrors mode = "Off"/> is often seen in the development and deployment of customErrors, so that detailed error information can be seen on the page. However, it also provides hackers with clues about attacks.

CustomErrors

This node has three optional settings

1. On: the safest option for server development, because it always hides error messages.
2. RemoteOnly: displays common error messages to most users, but displays complete error messages to users with server access permissions. In other words, only custom errors are displayed to remote clients and ASP. NET errors are displayed to local hosts. Default value.
3. Off: the most vulnerable option. It displays detailed error message to each user accessing the website.

Detailed error information may expose the internal structure of the application. For example, if an error is reported in an SQL statement, the data table and SQL statement may be exposed, which is very insecure. In the Off setting, hackers will constantly try to pass different parameters to make your website go wrong and then expose the internal structure of your application.

Mode = Off

For example:

<system.web>  <authentication mode="None" />  <compilation debug="true" targetFramework="4.5" />  
An exception is thrown directly in TestAction, so we can see yellow pages similar to the following

On the yellow pages, we can see that the page corresponds to the logical stack information, which exposes the project structure information. Very insecure.
If the mode is Off, and the error is recorded and cleared in the event Application_Error, what results will be seen?
Protected void Application_Error (object sender, EventArgs e) {var context = HttpContext. Current; if (context! = Null) {Exception objErr = context. Server. GetLastError (); if (objErr! = Null) {string err = "Error Caught in Application_Error event/n" + "Error in:" + Request. url. toString () + "/nError Message:" + objErr. message. toString () + "/nStack Trace:" + objErr. stackTrace. toString ();, and log Logic Server. clearError ();}}}
 <customErrors mode="Off" defaultRedirect="Error">    </customErrors>
DefaultRedirect specifies the default URL that the browser points to when an error occurs. If defaultRedirect is not specified, a general error is displayed. The URL can be absolute (for example, http: // www. ***. com/ErrorPage.htm) or relative. Relative URLs (such as/ErrorPage.htm) are relative to the Web. config file specified for defaultRedirect, rather than for webpages that generate errors. Using waveforms (~) URL (for example ~ /ErrorPage.htm) indicates that the specified URL is relative to the application root path.
Through the above operation, if you set Off and capture exceptions in the Application_Error event and Server. ClearError (), if an error is reported, a blank page is displayed on the front-end page.

This also indicates that if an application error occurs, the Application_Error event is triggered first, and the result is not displayed on the page after ClearError.
Mode = On
When the On mode is set, if an application error occurs, the custom error page is displayed. The defaultRedirect attribute is used here, <error statusCode = "500" redirect = "error"/>

Mode = RemoteOnly
Literally, what is remote? Let's take a look at the example. In the current encoding environment, the local host can be used as a server for users who want to access it remotely through the vs debugging status. This is local, and the Remote browser is Remote.

As you can see, on the server side, you can still see the yellow pages, that is, the ASP. NET error mentioned above. So what happens when we deploy the site on the server and access the site locally?

When you access the server url through a client, the default custom error page is displayed. What is the situation on the server?

Note: Only custom errors are displayed to remote clients and ASP. NET errors are displayed to local hosts.
 Summary
Therefore, do not disable customErrors in the production environment. We recommend that you enable RemoteOnly or On and define custom error pages.
The above is all the content of this article. I hope it will be helpful for your learning and support for helping customers.