Вызовите действие контроллера с перехватчика на Asp.Net MVC (Castle Windsor)

Question

Есть ли способ. Я хочу вызвать действие с параметром (или, по крайней мере, без параметров), как показано ниже.

Моя ситуация;

Перехватчик не содержит ссылок от MVC, Interceptor находится на уровне ApplicationService. Это услуга Interceptor.

public class ControllerInterceptor : IInterceptor 
    { 
     public void Intercept(IInvocation invocation) 
     { 
      var retVal = (ResponseDTOBase) invocation.ReturnValue; 
      if (retVal.ResponseCode == UsrNotAuth) 
      { 
       //Invoke Controller Action With passsing parameter (retVal) 
      } 

      invocation.Proceed(); 
     } 
    } 

Любые идеи? Благодарю.

Answer 1

Могу ли я предложить вам другой подход для авторизации запроса. MVC - это конечный автомат в своем основном принципе. У государственных машин есть действия, триггеры и охранники. В MVC уже есть такой «охранник» с целью перехвата действий контроллера и проверки прав пользователя. Это AuthorizeAttribute. Этот класс реализует IAuthorizationFilter. Другой аспект заключается в том, что авторизация и аутентификация должны произойти до того, как они достигнут ваших услуг. Что я имею в виду именно то, что есть два типа авторизации:

1. Авторизация Действие и
2. Authorization Data.

Первый тип авторизации, который вы можете реализовать с помощью AuthorizeAttribute или реализации пользовательского атрибута IAuthorizationFilter + FilterAttribute. Вот примера реализация такого атрибута для SPA (Single Application Page), который работает с помощью AJAX запросов:

атрибута:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = false)] 
public class LoggedOrAuthorizedAttribute : AuthorizeAttribute 
{ 
    public override void OnAuthorization(AuthorizationContext filterContext) 
    { 
     base.OnAuthorization(filterContext); 
     CheckIfUserIsAuthenticated(filterContext); 
    } 

    private void CheckIfUserIsAuthenticated(AuthorizationContext filterContext) 
    { 
     // If Result is null, we’re OK: the user is authenticated and authorized. 
     if (filterContext.Result == null) 
      return; 

     // If here, you’re getting an HTTP 401 status code. In particular, 
     // filterContext.Result is of HttpUnauthorizedResult type. Check Ajax here. 
     // User is logged in but this operation is not allowed 
     if (filterContext.HttpContext.User.Identity.IsAuthenticated && filterContext.HttpContext.Request.IsAjaxRequest()) 
     { 
      //filterContext.HttpContext.Response.StatusCode = 401; 
      JsonNetResult jsonNetResult = new JsonNetResult(); 
      jsonNetResult.Data = JsonUtils.CreateJsonResponse(ResponseMessageType.info, "msgOperationForbiddenYouAreNotInRole"); 
      filterContext.Result = jsonNetResult; 
      //filterContext.HttpContext.Response.End(); 
     } 
    } 
} 

Если вы используете чистый MVC есть пример осуществление here. Использование:

В контроллере

[LoggedOrAuthorized(Roles = Model.Security.Roles.MyEntity.Create)] 
public ActionResult CreateMyEntity(MyEntityDto myEntityDto) 
{ 
... 
} 

Вы можете применить это на каждом действии контроллера и блокировать пользователя еще до достижения контроллер.

Вы можете поставить регистраторов и другую «сантехнику» через замок Виндзор внутри ваших фильтров, чтобы записывать события.

Очень хорошие и важные ссылки и комментарии доступны в this Ответ на аналогичный вопрос. Эти ссылки обеспечивают очень хорошее руководство для правильной реализации.

Другой тип авторизации - авторизация доступа к данным может обрабатываться в службе или в контроллере. Я лично предпочитаю обращаться со всеми видами авторизации как можно скорее в конвейере.

Общая практика не показывает пользователю никаких данных или действий, которые он не разрешает просматривать или выполнять команды на нем. Конечно, вам нужно дважды проверить это, потому что пользователь может изменять запросы POST и GET.

Вы можете сделать простой интерфейс с реализацией IDataAccessService и управлять доступом к данным, передав ему идентификатор пользователя и идентификатор объекта.

Важно, чтобы вы не выбрали исключение, если пользователь не авторизовался, поскольку это не является исключением. Исключение означает, что ваша программа находится в неожиданном состоянии, которое запрещает ее нормальное выполнение. Когда пользователь не авторизован, это не является чем-то неожиданным - это очень хорошо. Вот почему в примере реализации сообщение возвращается, а не исключение.

Другая тонкость заключается в том, что «исключения» обрабатываются по-разному платформой .NET, и они стоят намного больше ресурсов. Это означает, что ваш сайт будет очень уязвим к простому отключению DDOS или даже может выполнять не так, как может. Общее правило заключается в том, что если вы контролируете ожидаемый поток программ за исключениями, вы не делаете это правильно - редизайн - это лечение.

Надеюсь, это поможет вам осуществить правильную реализацию в вашем сценарии.

Укажите тип авторизации, которую вы хотите получить, и параметры, которые у вас есть, поэтому я могу предложить более конкретную реализацию.