There is a generic authentication error which does not seem to hit any debug points, and ALWAYS sends the user to "/home/error".
I've searched far and wide, web.config, routing, etc... and can find no trace of a default error handling sending users to /home/error
I would really like to handle my own exceptions with custom messages, and this is preventing that. Any idea where I can look to find some manner of default error handling?
Related
I work on a number of Rails sites with forms and take advantage of Rails built-in authenticity token support. Works like a charm. Happy Happy Joy Joy.
It varies, but I would say I average about a SQL injection attack once a month that is successfully caught as having a failed authenticity token check. Wonderful.
The problem is the failed authenticity token check generates an ActionController::InvalidAuthenticityToken exception which returns an HTTP 5xx error because it is an unhandled exception. Good: the bad request is not allowed. Bad: The hacker is functionally informed that my server crashed which is hacker-code for KEEP ATTACKING THIS INTERFACE AT ALL COSTS because they aren't catching this error.
So what is the best way to handle this? If I simply try to wrap my controller method in a try/except, it doesn't even get to my method. It seems that if I want to respond with an access denied or some similar "bad user input" error (HTTP 4xx) then I would have to plug into the pipeline which seems like overkill for something the entire world has to deal with.
Also, what is the proper HTTP response? 400 (Bad Request)? Seems correct, but the other common scenario that generates this error is when a user pulls up your form from cache after the access token has timed out. In this case, the best user experience would be to simply refresh the form with a message saying it took too long for them to fill out the form or something like that. I suppose that could be in the body of an HTTP 400 response.
So how do I build this? Maybe something in the ApplicationController? Why isn't this the default? Maybe it is being handled properly and my "Unhandled Exception" reports are earlier in the pipeline?
All the errors that occur in our web application is logged to a database, and I'm finding a 404 error occurring hundreds of times in the last month. The page users are attempting to access is "https://companysite.com/applicationsite/:/0"
The application is a classic ASP site with some ASP.NET MVC 3 included through i-frames, although this error appears to be occurring on the classical ASP side judging by the URL.
I've done a search through the entire code (classic and .NET) for the string ":/0" but I'm not seeing anything. I'm at a loss at how this error is occurring. It is happening too often and for too many users to be intentional.
Would anyone happen to know why users are getting this error? Unfortunately I only have the database logs so I'm not really user how to reproduce this error, nor do I know how users are coming across it.
I would suspect that someone (outside of your site) is hitting that URL, which does not exist.
It could simply be that a spider has that URL indexed and is trying to crawl it. Or maybe that is a path to some application that has a vulnerability and someone is testing to see if you are running that application.
Try logging the IP address of where the request is coming from and also the User-Agent. If it is a web crawler, you should be able to see it in the User-Agent.
You could also block the IP address from accessing your site.
Which is the best way to handle a system error in ASP.NET MVC? I've watched a video on DimeCast.net in which the guy used the global.ascx file to write a method Application_Error to handle the errors. But currently, I'm handling my errors inside the web.config file.
Could someone point me in the right direction on how to properly handle errors? This could be:
syntax error
exceptions
404 and other page/file not found errors
The application is fairly large.
Take a look at elmah for logging of unhandled exceptions, there's actually a quick example on nuget demo video
I use combination of elmah for unhandled exceptions, and nLog to log ones that I can handle but still want to log. Thus far the combination has worked out very well.
Very likely you are going to need a combination of approaches. Some errors can be handled directly in your models, others in your controllers, and some others might need to be handled all the way to the application level (either via web.config or via the global.ascx.)
I prefer to handle the errors in the global.ascx rather than via redirection in web.config because in the global.ascx I have more information about the request that caused the error where as if I do a redirect via the web.config settings some of that information is lost by the time my error page receives the request.
A few weeks ago I just noticed that 404 errors are better not handled via the web.config because that (by design) causes an HTTP redirect code 302 rather than a true HTTP 404 code that indicates the client that the resource does not exist. I have a post on my blog where I cover this in detail http://hectorcorrea.com/Blog/Returning-HTTP-404-in-ASP.NET-MVC
Using ELMAH as Brook suggested is also a very good idea.
I am developing some SOAP web services using Ruby on Rails and considering how to handle generic failures. These generic errors are applicable to all the methods within the service and include the following :-
Missing Request element
Missing Authentication element (Custom)
Invalid Authentication details
I can intercept these errors within my controller before calling the relevant method and respond appropriately. My question is which implementation is easiest to manage from a Client perspective. My options for handling these errors seem to be as follows.
Raise an exception and let the SOAP service generate a SoapFault. This would be fine except I have little (no) control over the structure of the message contained within the SOAP fault.
Return an Http 400 response with an agreed data structure to indicate the error message. This structure would not be defined within the WSDL though.
Include a Status element in all responses, whether successful or not and have that status element include a code and an array of error data (Including error messages).
Option three seems like the best solution but is also the most error prone to implement as the implementation of web services in ROR precludes me from implementing this in a generic way and each method becomes responsible for checking the result of the checks and rendering an appropriate response. Admittedly this would be a single function call and return on failure but it is relying on the developer to remember to do this as we add more options.
I appreciate that most ROR developers will say that this should be implemented as a REST service and I agree, in fact we already have REST services to do this but the spread of SOAP in the corporate world, and its impressive tooling support means that we have to provide SOAP services to remain competitive.
In your experience what would be the easiest implementation for clients to handle and does this differ dependant upon the libraries/language of the client process.
A SoapFault would be the preferred way to signify errors. SoapFaults can contain additional information in their <detail> element.
The advantage of a SoapFault over some status element is that the caller can use standard exception handling, instead of checking for some status field.
I am using ELMAH to log errors in my asp.net MVC(C#) application.
I am able to log errors in xml or database. How to log errors to the eventlog using ELMAH?
ELMAH does not include an event log option.
ELMAH error log classes are not write-only; they also read the log data so that it can be displayed in the ELMAH web interface. Additionally, ELMAH logs more than just exception information. It also logs server variables, the form collection, and the information necessary to reproduce the yellow screen of death. Even if you were to log all of this information to the event log it would be difficult to read as plain text, and very difficult to read back in such a way that the ELMAH web interface could use it. If you are not going to use the ELMAH web interface then clearly that is not an issue.
If you want to log basic exception data to the event log you can create your own error log by subclassing ErrorLog. ELMAH supports multiple error logs, so you could continue to log detailed data to XML or a database (to service the ELMAH web interface) and then log a subset of that data to the event log.
Out of the box, you can't. You'd have to write a custom handler.
You can do something like this.
Elmah.ErrorSignal.FromCurrentContext().Raise(new Exception("My Exception");