Шаблоны авторизации службы WCF

Для вопроса 1 лучше всего сначала выполнить авторизацию. Таким образом, вы не передадите сообщения об ошибках проверки неавторизованным пользователям.

Кстати, вместо использования собственного метода проверки подлинности (который, как я предполагаю, является вашим CheckAccessPermission), вы можете подключиться к готовой поддержке WCF для поставщиков ролей ASP.NET. Как только это будет сделано, вы выполните авторизацию через OperationContext.Current.ServiceSecurityContext.PrimaryIdentity.IsInRole (). PrimaryIdentity - это IPrincipal.

Для вопроса 1 обязательно сначала авторизуйтесь. Никакой код (под вашим контролем) не должен выполняться до авторизации для обеспечения максимальной безопасности. Приведенный выше пример Павла превосходен.

Что касается вопроса 2, вы можете справиться с этим, создав подкласс своей конкретной реализации службы. Сделайте настоящую реализацию бизнес-логики абстрактным классом с помощью абстрактного метода CheckPermissions, как вы упомянули выше. Затем создайте 2 подкласса, один для использования WCF и один (очень изолированный в неразвернутой DLL), который возвращает true (или все, что вы хотите сделать в своем модульном тестировании).

Пример (обратите внимание, они не должны находиться в одном файле или даже в DLL!):

public abstract class MyServiceImpl
{
    public void MyMethod(string entityId)
    {
        CheckPermissions(entityId);
        //move along...
    }
    protected abstract bool CheckPermissions(string entityId);
}

public class MyServiceUnitTest
{
    private bool CheckPermissions(string entityId)
    {
        return true;
    }
}

public class MyServiceMyAuth
{
    private bool CheckPermissions(string entityId)
    {
        //do some custom authentication
        return true;
    }
}

Затем ваше развертывание WCF использует класс «MyServiceMyAuth», и вы проводите модульное тестирование против другого.

Что касается вопроса №2, я бы сделал это с помощью внедрения зависимостей и настроил бы вашу реализацию службы примерно так:

class MyService : IMyService
{
    public MyService() : this(new UserAuthorization()) { }
    public MyService(IAuthorization auth) { _auth = auth; }

    private IAuthorization _auth;

    public EntityInfo GetEntityInfo(string entityId)
    {
            _auth.CheckAccessPermission(PermissionType.GetEntity, 
                    user, entityId);

            //Get the entity info
    }
}

Обратите внимание, что IAuthorization - это интерфейс, который вы должны определить.

Поскольку вы собираетесь тестировать тип службы напрямую (то есть без запуска ее внутри инфраструктуры хостинга WCF), вы просто настраиваете свою службу на использование фиктивного типа IAuthorization, который разрешает все вызовы. Однако еще ЛУЧШИЙ тест - это имитировать авторизацию IA и проверить, что она вызывается, когда и с параметрами, которые вы ожидаете. Это позволяет вам проверить правильность ваших вызовов методов авторизации вместе с самим методом.

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

Я предпочитаю фреймворк для фиксации RhinoMocks, он бесплатный и имеет очень приятный свободный интерфейс, но есть и другие. Если вы хотите узнать больше о DI, вот несколько хороших примеров и фреймворков .Net:

• Мартин Фаулер на DI
• Джереми Миллер на DI
• Список контейнеров DI Скотта Хансельмана
• Мой личный любимый контейнер DI: Контейнер проекта Castle Windsor