Как добавить пользовательскую авторизацию в веб-сервис WCF с помощью DI

Question

Я пишу сервис WCF с использованием.NET 4.5 и SimpleInjector. Это REST-сервис (используется http/get/post).

Мне нужно добавить слой авторизации к моему сервису. После долгих раздумий у меня теперь есть собственный менеджер авторизации на основе ServiceAuthorizationManager.

Все примеры, которые я видел (и я нашел много), имеют жестко закодированную проверку имени пользователя и пароля. Я хотел бы использовать базу данных, и поэтому хочу внедрить слой данных в мой класс. Если я изменю конструктор на параметр, он выдаст исключение "Для этого объекта не определен конструктор без параметров".

Вот пример, на котором я основал свой код: https://msdn.microsoft.com/en-us/library/ms731774(v=vs.110).aspx Я добавил конструктор с интерфейсом:

public class MyServiceAuthorizationManager : ServiceAuthorizationManager
{
    public MyServiceAuthorizationManager (IMyDataLayer mdl)
    { ...

Пользовательская "Базовая" аутентификация для моих служб WCF. ОТДЫХ и РИА. Возможный?

Answer 1

Вероятно, вы настроили класс менеджера в соответствии с поведением вашего файла конфигурации (как показано в статье MSDN):

<serviceBehaviors>
  <behavior name="CalculatorServiceBehavior">
    <serviceAuthorization serviceAuthorizationManagerType="Samples.MyServiceAuthorizationManager,MyAssembly" />
  </behavior>
</serviceBehaviors>

В этом случае WCF полностью контролирует создание этого типа; не простой инжектор. Это означает, что для этого требуется конструктор по умолчанию.

Первое решение, которое приходит на ум, состоит в том, чтобы сделать этот класс Humble Object и позволить ему делегировать реальную логику аутентификации, которую вы помещаете в реальный сервис. По сути, это означает, что ваш Humble Object делает не что иное, как вызов контейнера, чтобы разрешить реальный сервис и вызвать соответствующий метод. Разрешение должно выполняться внутри класса Humble Object, и "реальный" сервис не должен кэшироваться.

Другой вариант - настроить ваш менеджер из кода (как показывает MSDN), разрешив его из контейнера и назначив WCF:

serviceHost.Authorization.ServiceAuthorizationManager =
    container.GetInstance<MyServiceAuthorizationManager>();

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