Mam niestandardowy filtr, którego używam od lat do obsługi RequestValidationException
s w bardziej przyjazny dla użytkownika sposób. To działa bez problemów we wszystkich scenariuszach dopóki nie wprowadzi obszar:Obsługa ASP.NET MVC RequestValidationException w obszarze
public class HandleHttpRequestValidationExceptionAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
//base.OnException(filterContext);
if (!(filterContext.Exception is HttpRequestValidationException))
return;
const string viewName = "~/Views/Errors/HttpRequestValidationException.cshtml";
var result = new ViewResult
{
ViewName = viewName,
ViewData = { Model = filterContext.Exception.Message }
};
//result.ViewBag.StatusCode = 200;
filterContext.Result = result;
filterContext.RouteData.Values["area"] = "";
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.Clear();
filterContext.HttpContext.Response.StatusCode = 200;
filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
filterContext.HttpContext.Server.ClearError();
}
}
... jest zarejestrowany w FilterConfig:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
//filters.Add(new HandleErrorAttribute());
filters.Add(new HandleMemberIsNotActivatedOrWaiveredAttribute());
filters.Add(new HandleMemberNotAuthorizedException());
filters.Add(new HandleHttpRequestValidationExceptionAttribute());
}
}
Wszelkie RequestValidationException
rzucony zostaje obsługiwane bez problemów (dostanę ładną stronę błędu z pewnym przyjaznym dla użytkownika opisem tego, co się stało i co z tym zrobić) , chyba że ktoś jest rzucony w obszar. W takim przypadku otrzymuję pustą odpowiedź z customErrors = "On" (i szczegółowym YSOD, jeśli customErrrors = "Off"). Jeśli usunę mój filtr, wtedy otrzymam brak szczegółów YSOD (który również jest bezcelowy). Tak czy inaczej, Application_Error w Global.asax.cs nie zostaje zwolniony. Co więcej, wszystkie moje inne filtry niestandardowe i obsługa wyjątków globalnych działa bez żadnych problemów, niezależnie od miejsca, z którego wyjątek został zgłoszony.
Jak obsługiwać RequestValidationException
w sposób przyjazny dla użytkownika, niezależnie od tego, skąd pochodzi wyjątek (niezależnie od tego, czy jest on wysyłany z poziomu Area
)?
Aktualizacja: nawet wykonanie filterContext.Result = new RedirectResult("/");
powoduje wyświetlenie tej samej pustej strony (i przejście przez nią oznacza, że wszystko jest w porządku, ale brak prawidłowej odpowiedzi).
Jest już zarejestrowana globalnie za pomocą FilterConfig (i po debugowaniu poprawnie przechodzi przez to). Mówisz, że to dziwaczny sposób na poradzenie sobie z niewiarygodnie dziwnym wyjątkiem? – Ted
I nie. Nie idź zgodnie z oczekiwaniami. Ponownie, rejestracja w FilterConfig rejestruje je już globalnie. Nie trzeba wtedy wyrzucać go jako atrybutu dla konkretnych kontrolerów. – Ted
Może być szalenie zapytać, ale w jaki sposób przekierowujesz trasę poza obszar z powrotem do głównych widoków. wouldnt ~/Views/Errors/HttpRequestValidationException.cshtml szuka tego widoku w obszarze. –