After implementing the Html.AntiForgeryToken() helper last Friday I had to think about handling error messages (not handling the errors itself) because the AntiForgeryToken concept is based on cookies - and if the user's browser does not support these, the user won't be able to access any single form on the site because each post request will raise a HttpAntiForgeryException.
I can live with that behaviour, but I don't want to show the user a generic error message but an detailed advise on what's going wrong and how he can solve that by himself (in other words I want to tell him how to enable cookies in his browser). So I had to handle the error and display the user a detailed error message with some more information than "Oh, we're sorry".
First thought: overwrite and customize the ValidateAntiForgeryTokenAttribute. But that's not possible, because this class is sealed, what's a good thing, too. Second thought (thanks to Albert): just using the HandleErrorAttribute.
With that attribute you can easily define views for specific errors. To not repeat myself and put that attribute to all of my controllers I created a simple base controller (which could be used for handling the errors - not only the error messages - in the future, too). All of my controllers are now inheriting from that base controller.
1: using System.Web.Mvc;
2:
3: namespace xyz.Website.Controllers
4: {
5: [HandleError(ExceptionType = typeof(HttpAntiForgeryException),
6: View = "ErrorMessages/NoCookieSupport")]
7: [HandleError(View = "ErrorMessages/Default")]
8: public class BaseController : Controller { }
9: }
1: public class AccountController : BaseController
2: {
3: // ...
4: }
Be aware of the order of the attributes, you should either place the most generic error at the end or define the order by the "Order" parameter of the attribute.
ASP.NET MVC automatically looks for views in it's known directories, by default in the current controller's directory followed by theViews/Shared directory. By indicate a Folder before the view's name you can organize your Shared folder a bit and not have to put all in one:
All you still have to do now is to enable custom errors in your web.config:
1: <customErrors mode="On|RemoteOnly|Off" />
That's the way how error messages were defined in ASP.NET since version 1 and it's pretty cool that MS has decided to keep this alive - so you can switch it locally to "Off" to see all exceptions thrown in detail and switch it to "On" or "RemoteOnly" in your website running live.
