Инъекция зависимостей (с использованием SimpleInjector) и OAuthAuthorizationServerProvider

Question

Новое для инъекций зависимостей, поэтому это, вероятно, простое дело, но я попытался и не могу понять, что я использую Simple Injector.

У меня есть WebApi, который отлично использует SimpleInjector, теперь я хотел бы реализовать безопасность с помощью OAuth.

Для этого я начал читать этот учебник, который очень полезен, но оленья кожи использовать зависимости Injection

http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/

У меня есть global.asax файл, глядя, как это, инъекцию установки зависимостей (рабочий совершенный)

protected void Application_Start() 
{ 
    SimpleInjectorConfig.Register(); 

    GlobalConfiguration.Configure(WebApiConfig.Register); 
} 

Я создал файл Startup.Auth.cs для настройки OAuth

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     var OAuthServerOptions = new OAuthAuthorizationServerOptions() 
     { 
      AllowInsecureHttp = true, 
      TokenEndpointPath = new PathString("/token"), 
      AccessTokenExpireTimeSpan = TimeSpan.FromDays(1), 
      Provider = new MyAuthorizationServerProvider() // here is the problem 
     }; 

     // Token Generation 
     app.UseOAuthAuthorizationServer(OAuthServerOptions); 
     app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions()); 
    } 
} 

Теперь, как я уже отмечал выше, проблема MyAuthorizationServerProvider. он принимает параметр IUserService, который я обычно вставляю. Я не хочу пустить конструктор, потому что мой IUserService также внедряет репозиторий. Вот файл

public class ApiAuthorizationServerProvider : OAuthAuthorizationServerProvider 
{ 
    private IUserService _service; 
    public ApiAuthorizationServerProvider (IUserService service) 
    { 
     _service = service; 
    } 

    public override async Task ValidateClientAuthentication(
     OAuthValidateClientAuthenticationContext context) 
    { 
     context.Validated(); 
    } 

    public override async Task GrantResourceOwnerCredentials(
     OAuthGrantResourceOwnerCredentialsContext context) 
    { 
     context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", 
      new[] { "*" }); 

     IUserService service = Startup.Container.GetInstance<IUserService>(); 
     User user = _service.Query(e => e.Email.Equals(context.UserName) && 
      e.Password.Equals(context.Password)).FirstOrDefault(); 

     if (user == null) 
     { 
      context.SetError("invalid_grant", 
       "The user name or password is incorrect."); 
      return; 
     } 

     var identity = new ClaimsIdentity(context.Options.AuthenticationType); 
     identity.AddClaim(new Claim("sub", context.UserName)); 
     identity.AddClaim(new Claim("role", "user")); 

     context.Validated(identity); 

    } 
} 

Как я могу заставить это работать с инъекцией зависимостей? Это должно произойти довольно много и должно быть в состоянии сделать что-то, чтобы справиться с этим. Я уверен, что это что-то простое, но я все еще учусь.

Answer 1

Когда вы начинаете с Injection Dependency, Owin, вероятно, не самый дружелюбный API для начала.

Я заметил эту часть в вашем коде:

IUserService service = Startup.Container.GetInstance<IUserService>(); 

Вы, вероятно, делают это как обходной путь, прежде чем узнать, как использовать конструктор. Но я думаю, что это ваш ответ прямо там. OAuthAuthorizationServerProvider - одноэлементный, поэтому ваш IUserService также будет синглтон, и все зависимости этого класса будут одинаковыми.

Вы упомянули, что используете репозиторий в своем сервисе пользователя. Вероятно, вы не хотите, чтобы этот репозиторий был singleton, поскольку я полагаю, что этот репозиторий будет использовать какой-то DbContext.

Таким образом, промежуточный ответ может быть решением, которое вы уже сделали. Возможно, есть более элегантное решение, если вы сделаете некоторое исследование того, что делает метод UseOAuthAuthorizationServer. Исходный код Katana можно найти здесь: Katana source code

Для регистрации других классов идентификации asp.net ссылка в комментарии DSR даст вам хорошую отправную точку.

Answer 2

Я Потребовалось некоторое время, чтобы выяснить, если это будет возможно зарегистрировать OAuthAuthorizationServerOptions в pipeling Owin с использованием метода app.Use() непосредственно, вместо app.UseOAuthAuthorizationServer() который просто метод расширения над app.Use(). app.Use() имеет перегрузку, где вы можете зарегистрировать делегат, который вы могли бы использовать для построения OAuthAuthorizationServerOptions.

К сожалению, это усилие зашло в тупик, потому что кажется, что даже если мы будем использовать делегат для построения, это, скорее всего, будет только однократно вызываться конвейером Owin, что приведет к такому же результату, экземпляр OAuthAuthorizationServerOptions, и, следовательно, все зависимости этого класса будут одинаковыми.

Таким образом, единственное решение, позволяющее сохранить работу, как должно быть, - это вытащить новый экземпляр вашего UserService каждый раз, когда вызывается метод GrantResourceOwnerCredentials().

Но для того, чтобы следить за Simple Injector design principles, было бы плохой дизайн, чтобы поддерживать зависимость от контейнера в классе ApiAuthorizationServerProvider, как показано на исходном коде.

Лучшим способом сделать это было бы использование фабрики для класса UserService вместо прямого вытягивания его из контейнера. В следующем коде показан пример того, как вы могли бы это сделать:

Прежде всего, очистите метод Application_Start() в файле global.asax и поместите весь свой код запуска в метод Owin Startup(). Код метода Startup():

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     var container = SimpleInjectorConfig.Register(); 

     GlobalConfiguration.Configure(WebApiConfig.Register); 

     Func<IUserService> userServiceFactory =() => 
       container.GetInstance<IUserService>(); 

     var OAuthServerOptions = new OAuthAuthorizationServerOptions() 
     { 
      AllowInsecureHttp = true, 
      TokenEndpointPath = new PathString("/token"), 
      AccessTokenExpireTimeSpan = TimeSpan.FromDays(1), 
      Provider = new ApiAuthorizationServerProvider(userServiceFactory) 
     }; 

     // Token Generation 
     app.UseOAuthAuthorizationServer(OAuthServerOptions); 
     app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions()); 
    } 
} 

Обратите внимание, как я изменил подпись функции SimpleInjectorConfig.Register(), возвращая укомплектовать сконфигурированный Простой Injector контейнер для вызывающего абонента, поэтому он может быть использован непосредственно.

Теперь измените конструктор вашего ApiAuthorizationServerProvider класса, поэтому фабричный метод может быть введен:

public class ApiAuthorizationServerProvider : OAuthAuthorizationServerProvider 
{ 
    private Func<IUserService> userServiceFactory; 

    public ApiAuthorizationServerProvider(Func<IUserService> userServiceFactory) 
    { 
     this.userServiceFactory = userServiceFactory; 
    } 

    // other code deleted for brevity... 

    private IUserService userService 
    { 
     get 
     { 
      return this.userServiceFactory.Invoke(); 
     } 
    } 

    public override async Task GrantResourceOwnerCredentials(
     OAuthGrantResourceOwnerCredentialsContext context) 
    { 
     // other code deleted for brevity... 
     // Just use the service like this 
     User user = this.userService.Query(e => e.Email.Equals(context.UserName) && 
      e.Password.Equals(context.Password)).FirstOrDefault(); 

     // other code deleted for brevity... 
    } 
} 

Таким образом, вы получаете новый UserService каждый раз метод GrantResourceOwnerCredentials() называется и полный граф зависимостей позади UserService класса будут соответствовать срокам жизни, которые вы определили в конфигурации Simple Injector, в то время как вы зависите от контейнера только в корне композиции приложения.

Answer 3

У меня были такие же проблемы в моем прошлом, я обошел эту проблему. Контейнер DI был StructureMap

https://www.linkedin.com/pulse/article/20140713170916-256089879-customclaim-based-authorization-in-net?trk=prof-post

Answer 4

Во-первых, это поздний ответ. Я просто написал это на случай, если кто-то еще столкнется с подобной проблемой и каким-то образом привязается к этой странице (например, мне) в будущем.

Предыдущий ответ является разумным, но не решает проблему, если служба фактически зарегистрирована на запрос веб-API, что, по моему мнению, является тем, что люди обычно делают, если они хотят использовать инъекцию зависимостей для объекта фреймворка идентификации, например UserManager.

Проблема заключается в вызове GrantResourceOwnerCredentials (обычно, когда люди попадают в конечную точку «токена»), простой инжектор не запускает жизненный цикл запроса api. Чтобы решить эту проблему, все, что вам нужно сделать, это запустить ее.

public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) 
    { 
     //...... 
     using (Startup.Container.BeginExecutionContextScope()) 
     { 
      var userService= Startup.Container.GetInstance<IUserService>(); 
      // do your things with userService.. 
     } 
     //..... 
    } 

С BeginExecutionContextScope простой инжектор запустит новую область контекста. Однако помните, что его нужно утилизировать явно.

Answer 5

Пока вы регистрируете распознаватель зависимостей для вашего WebAPI в вашем App_Start SimpleInjectorConfig.Register();

Как это

GlobalConfiguration.Configuration.DependencyResolver = new SimpleInjectorWebApiDependencyResolver(container); 

И если вы используете рекомендуемые AsyncScopedLifestyle Затем вы можете использовать распознаватель зависимости к получите новый пример ваших услуг, подобных этому

using (var scope = System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver.BeginScope()) 
{ 
    var _userService = scope.GetService(typeof(IUserService)) as IUserService; 
    //your code to use the service 
}