Использование классов пользовательских поставщиков
121ASP.NET --- Безопасность в ASP.NET --- Использование классов пользовательских поставщиков
Использовать поставщики Membership и Roles API, которые мы создали в предыдущих статьях, в веб-приложении довольно просто. Шаги, которые необходимо для этого выполнить, представлены ниже (не считая самых общих, таких как настройка аутентификации с помощью форм):
Если пользовательский поставщик инкапсулирован в отдельной библиотеке классов (что определенно удобно, если его планируется применять в нескольких веб-приложениях), добавьте ссылку на эту библиотеку классов через диалоговое окно Add References (Добавить ссылки) в Visual Studio.
Соответствующим образом сконфигурируйте пользовательский поставщик в файле web.config.
Укажите свой пользовательский поставщик как поставщик по умолчанию - либо с помощью ASP.NET WAT, либо вручную в файле web.config.
После завершения этих шагов конфигурации все готово к использованию поставщика. Если никакая специальная функциональность не добавлялась, а были только реализованы унаследованные классы то даже не придется изменять код приложения.
Конфигурация ранее созданных поставщиков XmlMembershipProvider и XmlRoleProvider в разделе <system.web> файла web.config выглядит примерно так:
<configuration>
<system.web>
<membership defaultProvider="XmlMembership">
<providers>
<add name="XmlMembership"
type="Professorweb.Providers.XmlMembershipProvider, XmlMembershipRolesProvider"
fileName="D:\Projects\WebSites\AspNetSecurity\Config\App_Users.config"
applicationName="security" />
</providers>
</membership>
<roleManager defaultProvider="XmlRoles" enabled="true">
<providers>
<add name="XmlRoles"
type="Professorweb.Providers.XmlRoleProvider"
fileName="D:\Projects\WebSites\AspNetSecurity\Config\App_Roles.config"
applicationName="security" />
</providers>
</roleManager>
<authentication mode="Forms">
<forms loginUrl="MyLogin.aspx"/>
</authentication>
</system.web>
</configuration>
В этом примере поставщики настроены на использование файлов, находящихся в каталоге D:\Projects\WebSites\AspNetSecurity\Config\, для хранения информации о пользователях и ролях. При такой конфигурации поставщики в ASP.NET WAT отображаются так, как показано на рисунке ниже:
Не пытайтесь тестировать поставщика в WAT; в данном случае он даст сбой. Тестирование поддерживается в WAT только для тех поставщиков, которые используют строки соединения с базами данных, лежащими в основе хранилищ. Поскольку используются XML-файлы, тестирование пользовательских поставщиков работать не будет.
При сохранении настроек конфигурации поставщика должны использоваться имена файлов с абсолютными путями. Если указан относительный путь, поставщик попытается создавать конфигурационные файлы в рабочей папке веб-сервера. Это приведет к генерации исключения, если учетная запись, от имени которой запущено веб-приложение, не имеет прав доступа к этой папке.
Отладка с применением WAT
Инструмент ASP.NET WAT использует классы Membership и Role для извлечения и обновления данных, сохраненных поставщиком членства. Хотя рекомендуется строить собственные тестирующие классы, которые вызывают все методы классов Membership и Role, определенно было бы удобно иметь возможность отладки из среды ASP.NET WAT, особенно если нужно исследовать проблемы, с которыми вы не сталкиваетесь при их тестировании вместе с приложением.
Для отладки с помощью WAT нужно просто запустить утилиту конфигурирования, выбрав в меню Website (Веб-сайт) пункт ASP.NET Configuration (Конфигурация ASP.NET), и подключиться к процессу веб-сервера, предоставляющего хостинг этому инструменту. Если при разработке применяется файловый веб-сервер, откройте диалоговое окно Attach to Process (Подключиться к процессу) Visual Studio, выбрав в меню Debug (Отладка) пункт Attach То Process (Подключиться к процессу). Найдите соответствующий процесс веб-сервера.
В большинстве случаев при использовании файлового веб-сервера будут работать два таких процесса, так что необходимо подключиться к тому из них, который имеет правильный номер порта. Выберите в диалоговом окне Attach То Process процесс, номер порта которого совпадает с номером, отображаемым в панели адреса браузера с загруженным инструментом ASP.NET WAT. После этого точки останова в классах поставщика будут работать, как положено. На рисунке ниже показано, как подключиться к веб-серверному процессу, который выделен для ASP.NET WAT:
Применение пользовательских поставщиков в IIS 8
Использование таких поставщиков через IIS очень просто и в точности соответствует конфигурированию реализаций поставщиков членства и ролей, описанному ранее.
Как только в каталоге bin приложения появляется реализация поставщиков членства и ролей (или когда они установлены в глобальном кэше сборок), IIS позволяет конфигурировать этот поставщик из консоли управления, что можно видеть на рисунке ниже:
После настройки пользовательского поставщика для .NET Users и для .NET Roles можно добавлять, редактировать и удалять пользователей непосредственно в консоли управления IIS 8. Никаких специальных требований в реализации поставщика соблюдать не понадобится. Единственное исключение состоит в том, что можно не включать зависимости от работающего экземпляра веб-приложения, такие как HttpContext, которые внутри консоли управления не доступны. Однако всегда необходимо следовать этому правилу при реализации пользовательских поставщиков.
И последний вопрос, на который нужно ответить прямо сейчас: как отлаживать пользовательские поставщики членства, когда они используются изнутри консоли управления IIS? Почему этот вопрос так важен? Дело в том, что может случиться так, что логика программы работает нормально в среде WAT, но неправильно - в консоли управления IIS (например, вы нечаянно использовали зависимость от работающего веб-приложения, подобную HttpContext). Обнаружение таких ошибок облегчается, когда возможна отладка приложения. Опять-таки, это очень просто. Вместо подключения к процессу веб-сервера, обслуживающему WAT, вы подключаетесь к процессу управления IIS (по имени InetMgr.exe), как показано на рисунке ниже:
Следует принять во внимание несколько моментов. Обычно консоль управления IIS запускается с административными привилегиями. Отладка приложения, работающего с административными привилегиями, требует также запуска Visual Studio с административными привилегиями. Для этого щелкните на значке Visual Studio правой кнопкой мыши и выберите в контекстном меню пункт Run As Administrator (Запуск от имени администратора). Затем, как показано на рисунке выше, отметьте флажки в нижней части диалогового окна Attach to Process в Visual Studio.