2009-10-22 18 views
17

Что является элегантным способом использовать существующие атрибуты [HandleError] и [Authorize] при работе с вызовами XHR с javascript?asp.net mvc [handleerror] [авторизовать] с JsonResult?

Итак, скажем, например, метод GetJson, который возвращает JsonResult.

При возникновении ошибки метод [HandleError] отправит обратно ViewResult, который будет восстановлен в функции обратного вызова в javascript.

я затем поместить пользовательский код везде в JavaScript, чтобы обрабатывать и перенаправлять любые сбои и т.д.

То, что я хотел бы сделать, это есть [HandleError] атрибут возвращает JsonResult если оригинал действие планировало это сделать. Это может быть принятие желаемого за действительное с моей стороны.

Аналогично, если приходит несанкционированный запрос Json, вместо того, чтобы возвращать новый HttpUnauthorizedResult, я хотел бы вернуть JsonResult, который позволяет моему коду на стороне клиента обрабатывать вещи обычным способом.

Я здесь лаяю неправильное дерево? Может быть, есть еще лучший способ, которым MVC может справиться с этим, о котором я не знаю?

Как другие люди справляются с этим сценарием?

Спасибо.

PS: Я понимаю, что могу создать свои собственные атрибуты [HandleJsonError] и [AuthorizeJson], которые возвращают JsonResults вместо ViewResults, но тогда мне придется ходить и размещать их на любом методе, который возвращает Json, и беспокоиться о Порядок фильтров и т. Д. Конечно, было бы неплохо, если бы я мог использовать отражение или что-то, чтобы один и тот же атрибут действовал по-разному в зависимости от подписи исходного метода.

ответ

27

У вас нет. Прямо сейчас, они не помогают JSON. Однако:

Я понимаю, что я могу создать свой собственный [HandleJsonError] и [AuthorizeJson] атрибуты, которые возвращают JsonResults вместо ViewResults, но тогда я должен был бы пойти вокруг и разместить их на любой метод, который возвращает JSON, и беспокоиться о порядке фильтра и т.д.

то, что мы сделали это подтипа существующие атрибуты, и заставить их работать условно:

public sealed class AjaxAuthorizeAttribute : AuthorizeAttribute 
{ 
    public override void OnAuthorization(AuthorizationContext filterContext) 
    { 
     base.OnAuthorization(filterContext); 
     if (filterContext.Result == null) 
     { 
      return; 
     } 
     else if (filterContext.Result.GetType() == typeof(HttpUnauthorizedResult) 
      && filterContext.HttpContext.Request.IsAjaxRequest()) 
     { 
      filterContext.Result = new ContentResult(); 
      filterContext.HttpContext.Response.StatusCode = 403; 
     } 
    } 
} 

Теперь код JS может выглядеть Ф.О. r 403 (потому что ASP.NET ест 401 и возвращает страницу с ошибкой) и тот же атрибут работает для Ajax и не-Ajax. Поэтому проблем с фильтрами нет.

+0

Спасибо! Request.IsAjaxRequest() очень полезно. Я не знал, что это было. – Scott

+0

Это метод расширения, который добавляет MVC. На самом деле это не часть запроса. –

+1

Спасибо! Это очень элегантный способ и должен быть отмечен как правильный ответ. Однако конструктор не нужен. –

Смежные вопросы