My event log has thousands of entries for code 3003 which says "A validation error has occurred.". I am properly handling the validation on server side and error is caught in global.asax and proper message is shown to the user. I don't want to add code to handle the characters on client side by javascript or turning on ValidateRequest=false
My concern is only the event log entries and is there any way I can stop asp.net not to log event 3003 in event log?
Just add:
<pages validateRequest="false" enableEventValidation="false"/>
To your web.config to apply it to the whole site.
Edit:
Goes in the System.web section.
Related
I am making an online bug tracking system(BTS) in ASP.NET. I am using Gridview for displaying the records on a web page. It is working properly in some web forms but in some web forms, i am getting error as given below when i click edit event of gridview. Please guide me to solve this error.
Server Error in '/BTS' Application.
Invalid postback or callback argument. Event validation is enabled using
<pages enableEventValidation="true"/> in configuration or <%# Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
Just do this --> EnableEventValidation="false" like below
<%# Page Title="" Language="C#" MasterPageFile="~/shirish.master" AutoEventWireup="true"
CodeFile="s.aspx.cs" Inherits="_s" EnableEventValidation="false" %>
This is a typical error in ASP.NET when request validation fails. The most common scenario is when you are issuing a postback and one of the input controls (usually a TextBox) contains html or javascript code. As the error message states, there's several ways you can bypass this validation:
By disabling request validation at the page level which be achieved by setting the EnableEventValidation property of the page directive to false. Note that you can do the same site-wide from the web.config file
By registering the required control for event validation using the ClientScriptManager.RegisterForEventValidation method
If you use the first approach, you will be turning off event validation which means you will be relaxing some of the built-in security features. On the other hand, the second approach is a bit clumsy because it requires to anticipate the values allowed by the control
I am working on an ASP.NET web application. I am implementing the logging framework for the entire application.
web application has around 7-8 pages and is a simple CRUD operations web application.
Its an Azure hosted application. Following is the approach i am following for logging and exception handling.
1) Added Try...Catch blocks in the Data Access Layer, and Click events.
2) Upon catching errors, I am propagating the exceptions upto the Globabl.asax leve, and in Application_Error event logging the error into Event Logs and Trace Logs.
3) After this in the Global.asax file I am Redirecting to an Error Page to show a User Friendly Message and link to the failed page.
4) Just wanted to know whether is it a good approach to do this.
Thanks Friends.
Are you actually handling exceptions on the DAL (ie, logging, trying to fix it, etc)? If not, then the try catch serves no purpose other than spinning cycles. The same is true for the click events, but it is not a bad practice to handle errors on the UI, even if you are not truly doing anything with them, as you will divert the user from the ugly error page to your own friendly message.
A single error page works fine, if you truly cannot handle the exception thrown. The upside is time to market, as you write precious little code to avoid showing the user an ugly message. The downside is the user misses context. I am not really up on the one size fits all exception handler, except as a backup (have an error I did not envision that got past my first line handler).
There is a variation of the common error page, if you are handling based on HTTP statuses and that is to use config.
Another pattern is to set up your own base page and have it work as an error handler. You can then set aside a container to fill when an error occurs. This approach works nicely for adding context, as the user still sees part of the page he was on, but you have given an error message, so he knows things have failed. I have seent this pattern used with a user control that is added to the container when an error occurs, but this is a bit more invovled, as you have to set up a table of codes and proper messages to show (which can be buggy in and of itself).
Why not using ASP.NET custom error pages ? You can specify each error page for each status code or you can specify a default redirect.
You can configure this in the web config and you are all set.
<customErrors defaultRedirect="GenericError.htm" mode="On">
<error statusCode="404" redirect="notfound.htm"/>
</customErrors>
You can configure it for showing the custom error pages to all users or only to remote users etc..
http://aspnetresources.com/articles/CustomErrorPages
I totally agree that you should log all errors in your catch block and write it to a log.
It sounds like you're kind of reinventing the wheel here. ASP.NET already includes things to help you achieve the desired result. Unless you need handling logic to cleanup after the errors, I wouldn't use try catch blocks. Have a look at the ASP.NET Health Monitoring Overview for logging errors. As far as presenting a custom error page see How to create custom error reporting pages in ASP.NET by using Visual C# .NET.
I think, You need not to use Exception Handling. Suppose You have a Presentation Layer and a Business Logic Layer/DataAccess Layer.
Upon facing the error in say Business Logic, it will move directly to Glogal.asax.cs file under Application_Error Event without going back to the calling function. Here you can log the error message like below....
HttpContext.Current.Server.GetLastError().InnerException.StackTrace
HttpContext.Current.Server.GetLastError().InnerException.Message
HttpContext.Current.Server.GetLastError().InnerException.Source
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.FullName
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Name
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Namespace
Now in the Web Config you can write code to redirect the user on some default page like below.
<customErrors defaultRedirect="ErrorPage.htm" mode="On">
<error statusCode="404" redirect="ErrorPageNotFound.htm"/>
</customErrors>
Per our policy we are no longer allowed to write to event log, so I removed all my event log code from writing to the event log, which works, however I keep getting random ASP.NET 4.0 Warnings from the errors, even though I have code in my Application_Error to handle all errors.
Any way to disable event logging completely, maybe a web.config change or IIS setting to disable it?
Noticing it for a lot of errors too.. not just my HTTPHandler
Example of the EventLog record:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 9/8/2011 10:26:04 AM
Event time (UTC): 9/8/2011 2:26:04 PM
Event ID: 6b56761296d24e1aa01038ce125be044
Event sequence: 97
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT/-2-129599642336131368
Trust level: Full
Application Virtual Path: /
Application Path:
Machine name:
Process information:
Process ID: 6396
Process name: w3wp.exe
Account name: IIS APPPOOL\MyAppPool
Exception information:
Exception type: System.Exception
Exception message: STACKTRACE
The default behavior of ASP.NET is to write unhandled exceptions to the event log. The way to prevent it from writing them to the event log is to handle them yourself. You can do this via your Global.asax file in the Application_OnError handler.
You can also call Server.ClearError() to prevent it from bubbling up to any other handlers.
It's true that the default behavior is to log all unhandled exceptions to Application event log as explained in this answer. This behavior is controlled by <system.web><healthMonitoring> element in web.config and default settings are shown here. The idea is that for every unhandled exception an instance of System.Web.Management.WebBaseErrorEvent is raised and then ASP.NET default settings cause it to be logged into Application event log.
You could handle all errors or you could change ASP.NET settings. Rules which cause these events to be logged can be changed using <system.web><healthMonitoring><rules>. Since you say you're prohibited from writing into the event log I would guess your best bet is to just erase the default rules as explained here:
<healthMonitoring>
<rules>
<clear />
</rules>
</healthMonitoring>
which removes the two default rules each causing writes to event log.
Sorry for my English.
I have a strange problem.
When user click adword link, Google write tracking cookie like that
1813234232.1302674912.30.51.utmgclid=CcgezrsXjagCFcs-zAod_h2oCQ|utmccn=(not set)|utmcmd=(not set)|utmctr= CAA:89 AB0=40#B%20>:
In keyword section(utmctr) there is bad braskets, that cause request validation exception
A potentially dangerous Request.Cookies value was detected from the client (__utmz="...0=40#B%20> at System.Web.HttpRequest.ValidateCookieCollection(HttpCookieCollection cc)
Is there any way to solve this problem without turning off request validation?
Edited
I'm probably found obvious solution: write own request validation module http://jefferytay.wordpress.com/2010/04/15/creating-your-own-custom-request-validation/
By default asp.net validate and check the data for potential attacts.
You can disable this automatic validation by set validateRequest="false" ether on page
<%# Page validateRequest="false" %>
ether on web.config that affect all pages.
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
The only think that you need to check by your self after that, is if someone enters any script data to your inputs. Your inputs then need to check out when you render them on the page, and when you enter them on the database.
This question is kind of related to Handle URI hacking gracefully in ASP.NET in that it's too about how to best handle exceptions that occur during an ASP.NET request lifecycle. I've found a way to handle most exceptions gracefully, but then I've found that some exceptions occur so late in the request that there's no way to do stuff like Server.Transfer to compartementalize the whole error presentation logic into its own page.
So, I have to handle the exception inside the Application_Error event instead, and do Response.Writes and whatnot. It's ugly. I understand that in some circumstances the response stream could have already been flushed, so transferring the request isn't really an option. What I want to ask is if there's anyone who's found an elegant solution to this problem?
Also, I find it difficult to know when I can handle the exception gracefully by transferring the request to another page and not. What is the best way to find out where in the request lifecycle we're at when an exception occurs? If it occurs during the loading and rendering of a page, Page_Error will be able to handle it and I've not had a problem doing Server.Transfer there yet. But if the exception occurs either too early or too late for Page_Error to catch it and it bubbles to Application_Error, what do I do to know whether it's early or late?
If it's late in the lifecycle, I'll probably have to do Response.Write directly from Application_Error, but if it's early I can do Server.Transfer. The problem is that trying to do Server.Transfer will itself cause an exception if it's too in the request to do it.
So, is there a global enumeration or something similar that will indicate whether it's too late to do creative stuff with the response or not?
I have used this approach to catch all errors generated, either in web controls or pages. All it requires you to do is to inherit from a base class (one for pages and one for usercontrols) each page or usercontrol can implement its own HandleException method and do whatever it needs to do.
Full code here:
Transparent generic exception handling for asp.net / MOSS2007 (with code)
I think my advice for this would be to use ASP.NET Health Monitoring with WMI Events provider for the errors:
Here is a how to.
http://msdn.microsoft.com/en-us/library/ms178713.aspx
Hope this helps:
Andrew
I suggest that you use asp.net configuration to have a general error page for the unhandled exceptions. From the sample web.config
<!--
The <customErrors> section enables configuration
of what to do if/when an unhandled error occurs
during the execution of a request. Specifically,
it enables developers to configure html error pages
to be displayed in place of a error stack trace.
<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
-->
On the overall handler, just log the exception, and let asp.net do the redirect.
If you still want to go on with your customer approach, I suggest you look at the available asp.net source and check how it is doing that.