Нашли ошибку или опечатку? Выделите текст и нажмите

Поменять цветовую

гамму сайта?

Поменять
Обновления сайта
и новые разделы

Рекомендовать в Google +1

Настройка Membership API

158
1

Прежде чем можно будет использовать интерфейс Membership API и элементы управления безопасностью ASP.NET, потребуется выполнить несколько шагов:

  1. Сконфигурируйте аутентификацию с помощью форм в файле web.config обычным образом и запретите доступ анонимным пользователям.

  2. Настройте хранилище данных членства. Например, если используется SQL Server, то в базе данных SQL Server придется создать несколько таблиц и хранимых процедур.

  3. Сконфигурируйте в файле web.config строку подключения к базе данных и поставщика членства, который должен использоваться.

  4. Создайте пользователей в хранилище данных членства с помощью веб-утилиты конфигурирования ASP.NET, либо воспользуйтесь собственной страницей администрирования, которая может быть реализована в веб-приложении с применением функций Membership API.

  5. Создайте страницу входа, которая использует готовый элемент управления Login или класс Membership для проверки введенных удостоверений и аутентификации пользователей.

Все шаги по конфигурированию за исключением настройки поставщика можно выполнить с помощью ASP.NET WAT (Web Site Administration Tool - инструмент администрирования веб-сайтов), в состав которого входит мастер настройки безопасности. Выберите в меню Website (Веб-сайт) пункт ASP.NET Configuration (Конфигурация ASP.NET) в среде Visual Studio. Интерфейс WAT показан на рисунке ниже:

Настройка безопасности в WAT

Если ASP.NET используется на машине с установленной версией SQL Server Express Edition, то не придется даже настраивать хранилище данных и конфигурировать поставщика членства. Просто запустите мастер настройки безопасности в WAT и начните с добавления пользователей в хранилище членства. Необходимое хранилище данных создается автоматически, как только будет создан первый пользователь. Причем оно будет создано автоматически, даже если к нему производится обращение программно, поскольку эта функциональность обеспечивается через SqlMembershipProvider.

Однако имейте в виду, что это работает только с SQL Server Express Edition! В случае применения какой-то другой версии SQL Server хранилище данных придется конфигурировать вручную, как будет описано в разделе "Создание хранилища данных" далее в статье.

Когда работа ведется с SQL Server Express Edition, класс SqlMembershipProvider автоматически создает новую базу данных по имени ASPNETDB.MDB в специальном каталоге App_Data веб-сайта. Эта база данных реализует полную схему, что необходимо для хранения и управления информацией о пользователях, ролях, назначения ролей пользователям и даже более того - для персонализации и профилей пользователей.

Если возникнет желание использовать в качестве хранилища информации о пользователях и ролях собственную базу данных, а не автоматически созданную, для этого понадобится сконфигурировать поставщика членства и информацию для его подключения, прежде чем запускать мастер настройки безопасности в WAT. Все шаги конфигурирования и работа Membership API "за кулисами" подробно рассматривается в последующих разделах.

Конфигурирование аутентификации с помощью форм

Интерфейс Membership API основан на аутентификации с помощью форм и предлагается в виде готовой к применению инфраструктуры для управления и аутентификации пользователей. Таким образом, в качестве первого шага приложение должно быть сконфигурировано на аутентификацию с помощью форм. Но на этот раз структура решения будет немного отличаться.

Часто к корневому каталогу приложения открывается доступ для анонимных пользователей, в то время как ограниченные ресурсы сохраняются в подкаталогах с ограниченным доступом. Эти подкаталоги имеют собственные файлы web.config, которые закрывают доступ анонимным пользователям. Как только кто-то пытается обратиться к ресурсам, расположенным в защищенном каталоге, исполняющая среда ASP.NET автоматически перенаправляет пользователя на страницу входа.

На рисунке ниже показана структура веб-приложения, которая отображена в проводнике решений (Solution Explorer) уже структурированного проекта Visual Studio:

Структура папок и файлов веб-приложения с защищенной областью

Таким образом, в корневом каталоге веб-приложения нужно только сконфигурировать аутентификацию с помощью форм, включив следующий фрагмент:

<system.web>
      <authentication mode="Forms">
        <forms loginUrl="MyLogin.aspx" />
      </authentication>
</system.web>

Как видите, эта конфигурация указывает на применение аутентификации с помощью форм и открывает анонимный доступ к страницам. В защищенный подкаталог должен быть помещен дополнительный файл web.config со следующим содержимым:

<system.web>
      <authorization>
        <deny users="?"/>
      </authorization>
</system.web>

Эта конфигурация запрещает доступ любому анонимному пользователю к защищенной вложенной папке веб-сайта. Если какой-то не аутентифицированный пользователь попытается обратиться к ресурсам из этого каталога, то исполняющая среда ASP.NET автоматически перенаправит его на страницу входа (публично доступную). Естественно, понадобится создать страницу входа, но с помощью Membership API это намного легче и быстрее, в чем вы убедитесь, когда будете изучать элемент управления Login в следующей статье.

Создание хранилища данных

С помощью Membership API необходимо настроить хранилище данных, с которым будет работать ваш поставщик членства. Как уже упоминалось ранее, при использовании SQL Server Express Edition в сочетании с ASP.NET класс SqlMembershipProvider способен создать это хранилище автоматически.

Однако в случае применения любой другой версии SQL Server это хранилище должно создаваться вручную. Есть и ряд других причин для того, чтобы не использовать автоматически присоединяемую, основанную на файлах базу данных. Этими причинами являются производительность и параллелизм. Изложим некоторые основы.

В SQL Server Express Edition базы данных можно использовать двумя способами. Первый способ - классический, а это означает, что вы создаете или присоединяете базу данных к SQL Server Service, как привыкли это делать в предыдущих версиях. Система SQL Server затем получает полный контроль над базой данных и способна предоставить эту базу данных множеству приложений и множеству пользователей одновременно.

Второй режим - тот, в котором SQL Server Express Edition может применяться в режиме на основе файлов. Это значит, что приложение может обращаться к файлу базы данных SQL Server непосредственно, не подключая его к экземпляру SQL Server. Система SQL Server динамически подключает и отключает базу от локально выполняющейся версии SQL Server Express Edition всякий раз, когда требуется информация из этой базы данных. Поэтому файл базы данных блокируется только на короткий период времени (по сравнению с подключенными базами данных, которые блокируются сервером SQL Server на все время, пока работает служба SQL Server). Это облегчает копирование файла базы данных, поскольку он не блокирован (например, если нужно скопировать внесенные изменения на машину развертывания и т.п.).

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

Режим базы на основе файлов подходит для клиентских приложений Windows, использующих SQL Server Express Edition на стороне клиента в качестве хранилища данных клиентской стороны, где в каждый момент времени один пользователь и одно приложение обращается к базе данных. Это удобно также для целей разработки, поскольку не понадобится управлять базами данных для всех проектов в SQL Server через Management Studio. Однако эта опция не очень подходит для рабочих сред, когда множество пользователей используют ваши (и, возможно, другие) веб-приложения, обращающиеся к содержимому базы данных.

Поэтому для рабочих сред рекомендуется ручное создание базы данных членства, как описано в настоящем разделе. В случае SqlMembershipProvider создание такого хранилища данных означает создание базы данных SQL Server и множества таблиц и хранимых процедур в ней. ASP.NET поставляется с множеством сценариев SQL, которые позволяют вручную создать необходимую базу данных и ее таблицы, необходимые для хранения информации о пользователях и ролях, используемой Membership API. Однако ASP.NET также поставляется с инструментом aspnet_regsql.exe, который создает таблицы автоматически. В случае специального поставщика потребуется подготовить и настроить источник данных, применяемый этим поставщиком, в соответствии с его документацией.

Инструмент aspnet_regsql.exe можно использовать двумя способами: либо через интерфейс мастера, либо из командной строки, указывая специальные переключатели командной строки. В любом случае понадобится запустить инструмент в окне командной строки Visual Studio, поскольку оно включает всю необходимую настройку путей к каталогу .NET Framework, содержащему нужные инструменты. Если вы просто запустите его без параметров, то увидите на экране интерфейс мастера, который проведет по всему процессу создания базы данных (утилита находится по адресу C:\Windows\Microsoft.NET\Framework\[Версия]):

Пользовательский интерфейс мастера aspnet_regsql.exe

На рисунке показано создание базы данных на SQL Server Express Edition. Поэтому для идентификации именованного экземпляра SQLEXPRESS к идентификатору (.\) машины вручную добавляется суффикс SQLEXPRESS. Это значит, что новая база данных будет создана на экземпляре SQL Sever по имени SQLEXPRESS. Кроме того, она создается как полноценная подключенная база данных (а не файловая версия, создаваемая автоматически). Именно так необходимо вручную создавать базу данных для полной версии SQL Server: либо просто опустить имя экземпляра (в этом случае SQLEXPRESS), либо указать собственное имя экземпляра. При установке SQL Server на целевую машину есть возможность выбрать имя экземпляра.

Мастер предоставляет выбор - создать необходимую базу данных или удалить таблицы из существующей. Если выбрать опцию <default> для базы данных, мастер ищет базу данных по имени aspnetdb на указанном сервере. Если таковая еще не существует, aspnet_regsql.exe создает ее, и в ней создаются необходимые таблицы. Если таблицы уже существуют в целевой базе данных, они остаются неизменными.

Как упоминалось ранее, инструмент aspnet_regsql.exe можно также использовать в командной строке. На самом деле, это хороший способ автоматизировать установку приложения - просто вызвать этот инструмент из командной строки и автоматически установить таблицы базы данных ASP.NET, требуемые для приложения. Например, чтобы установить таблицы базы данных Membership API, необходимо запустить следующую команду:

aspnet_regsql -S .\SQLEXPRESS -E -A all -d MyDatabase

Результат выполнения этой команды показан на рисунке ниже:

Выполнение aspnet_regsql.exe для установки базы данных

И снова обратите внимание, что вы работаете с локальным экземпляром SQL Server по имени SQLEXPRESS (которым является SQL Server Express Edition, установленный на вашей машине). Однако поскольку здесь создается полноценная, подключенная база данных, такой способ будет работать с любой версией SQL Server. В стандартной установке полноценной версии SQL Server (Standard или Enterprise) нужно опустить имя экземпляра (\SQLEXPRESS) или указать имя экземпляра, выбранное при установке SQL Server.

В таблице ниже перечислены наиболее важные переключатели командной строки инструмента aspnet_regsql.exe, необходимые для Membership API и связанных с ним служб приложений ASP.NET:

Переключатели командной строки aspnet_regsql.exe
Переключатель Описание
-S имя_сервера

Указывает сервер SQL Server и экземпляр, для которого нужно установить таблицы базы данных ASP.NET. В качестве хранилища для Membership API можно использовать SQL Server 7.0 или более новые версии

-U имя_пользователя

Имя пользователя базы данных SQL Server, под которым необходимо подключаться к базе. Этот параметр обязателен, если вы не хотите применять аутентификацию Windows только для подключения к SQL Server

-P пароль

Если задан переключатель -U, необходимо также указать пароль. Параметр обязателен, если вы не хотите применять аутентификацию Windows только для подключения к SQL Server

-E

Если не указаны переключатели -U и -P, автоматически осуществляется подключение с аутентификацией Windows к серверу базы, заданному в переключателе -S. Переключатель -E позволяет явно указать, что к SQL Server необходимо подключиться через аутентификацию Windows

-C

Позволяет указать полную строку соединения ODBC или OLEDB для подключения к базе данных

-sqlexportonly

Создает SQL-сценарии для указанных опций без установки их в выделенном экземпляре SQL Server

-A

Устанавливает службы приложений. Допустимыми опциями для этого переключателя являются all, m, r, p, c и w. В предыдущем примере команды использовалась опция all для установки всех служб приложений; m предназначена для членства; r означает службы ролей; p - профили ASP.NET для поддержки пользовательских профилей; c - персонализацию частей веб-страниц; w - поставщика SQL веб-событий

-R

Удаляет установленные службы приложений. Этот переключатель поддерживает те же опции, что и -A, и удаляет соответствующие таблицы базы данных служб приложений

-d

Позволяет дополнительно указать имя базы данных, в которой необходимо установить службы приложений. Если не задать этот параметр, автоматически создается база данных по имени aspnetdb (как и в случае с опцией <default> в графическом интерфейсе мастера)

Инструмент aspnet_regsql.exe имеет также несколько дополнительных переключателей для установки состояний сеанса SQL Server, а также для конфигурирования зависимостей кэша SQL.

Сценарии базы данных для служб ASP.NET

Инструмент aspnet_regsql.exe выполняет несколько сценариев для создания (или удаления) базы данных членства и ее таблиц. Эти сценарии входят в состав .NET Framework; их можно найти в каталоге .NET Framework, как показано на рисунке ниже:

SQL-сценарии для установки и удаления баз данных SQL

Существуют два типа сценариев - Install ... и соответствующие им Uninstall ... В то время как Install... устанавливают набор таблиц баз данных, таких как таблицы, необходимые для Membership API, сценарии Uninstall... удаляют те же таблицы и базы данных. В таблице ниже описаны сценарии установки, включенные в .NET Framework:

Сценарии установки Membership API
Сценарий Описание
InstallCommon.sql

Устанавливает некоторые общие таблицы и хранимые процедуры, необходимые и для Membership.API, и для Roles API. Это включает таблицы для идентификации приложений ASP.NET, которые используют другие средства ASP.NET, такие как Membership API, службу ролей, а также персонализацию

InstallMembership.sql

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

InstallRoles.sql

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

InstallPersonalization.sql

Содержит команды DDL для создания любой таблицы и хранимой процедуры, необходимой для создания персонализированных портальных приложений с помощью Web Parts

InstallProfile.sql

Создает все необходимые таблицы и хранимые процедуры для поддержки пользовательских профилей ASP.NET

InstallSqlState.sql

Устанавливает таблицы для постоянных состояний сеансов в базе данных TEMP на сервере SQL Server. Это значит, что каждый раз, когда служба SQL Server останавливается, состояние сеанса теряется

InstallPersistSqlState.sql

Устанавливает таблицы для постоянных состояний сеансов в отдельной базе данных ASPState. Это значит, что состояние сеансов сохраняется даже после перезапуска службы SQL Server

Если вы не хотите или не можете использовать aspnet_regsql.exe, эти сценарии можно выполнить через инструмент командной строки sqlcmd.exe. Например, для установки общих таблиц на сервере SQL Server Express Edition служит следующая команда:

sqlmnd -S .\SQLExpress -E -i InstallCommon.sql

Помните, что запускать эти сценарии не понадобится, если вы применяете aspnet_regsql.exe, поскольку данная утилита как раз и выполняет эти сценарии самостоятельно. Рекомендуется использовать aspnet_regsql.exe, когда это возможно, и обращаться к сценариям напрямую только в ситуациях, когда по какой-то причине применять aspnet_regsql.exe нельзя. (Причиной может быть политика в отношении информационных технологий, настройка сценариев SQL или же включение стандартных сценариев SQL в собственные сценарии SQL, которые применяются для развертывания приложения.) Однако вместо включения этих сценариев SQL в собственные сценарии развертывания рекомендуется добавить либо специальный код, либо командные файлы в пакет развертывания, а в них вызвать aspnet_regsql.exe.

С помощью переключателя -S указывается сервер и имя экземпляра целевого сервера SQL Server. Обычно имя экземпляра (заданное после \) не используется, но сервер SQL Server Express Edition устанавливается как именованный экземпляр, что позволяет впоследствии установить на той же самой машине другие версии и экземпляры SQL Server. Таким образом, для SQL Server Express Edition должно быть указано имя экземпляра, которым по умолчанию является SQLEXPRESS. В переключателе -E указывается, что доступ к SQL Server осуществляется через аутентификацию Windows, и, наконец, в переключателе -i задается входной SQL-сценарий, который должен быть выполнен.

На рисунке ниже показан результат выполнения предыдущей команды:

Установка таблиц базы данных ASP.NET на SQL Server Express

Не пугайтесь сообщений об ошибках. Поскольку эта команда выполняется администратором, выводятся сообщения об ошибках, т.к. невозможно выдавать, забирать или ограничивать привилегии системного администратора (sa, dbo, sys и т.д. - администратор владеет всеми правами).

Конфигурирование строки соединения и поставщика членства

При наличии установленного SQL Server Express Edition в конфигурации по умолчанию специально подготавливать хранилище данных и настраивать поставщик членства не понадобится, поскольку исполняющая среда ASP.NET использует поставщик SQL Server на основе файлов и создает необходимую базу данных автоматически.

Если же установленной копии SQL Server Express Edition нет, то хранилище должно быть создано вручную, как было описано в предыдущем разделе, а поставщик членства - сконфигурирован, как описано в настоящем разделе. Помните, что поставщик членства должен быть сконфигурирован в корневом файле web.config веб-приложения (имеется в виду файл web.config, размещенный в корневом каталоге веб-приложения). Это означает, что приведенная ниже конфигурация должна находиться в корневом web.config, а не в web.config внутри подкаталога веб-сайта, поскольку она затрагивает все веб-приложение.

Но если вы захотите использовать собственную базу данных SQL Server или даже собственного поставщика членства и хранилища, то придется соответствующим образом сконфигурировать этого поставщика, а также строку соединения с базой-хранилищем данных о членстве. Для этого нужно будет непосредственно модифицировать файл web.config или редактировать конфигурацию с помощью оснастки IIS консоли MMC, если приложение выполняется под управлением IIS.

В случае применения хранилища SQL Server (или другого хранилища на основе базы данных) первым делом должна быть настроена строка соединения. Это можно сделать в разделе <connectionStrings> файла web.config. Например, если используется локальная база данных по имени aspnetdb, в которой установлены таблицы с помощью инструмента aspnet_regsql.exe, как было показано ранее, то строка соединения должна выглядеть следующим образом (вспомните, что раздел <connectionStrings> находится непосредственно под элементом configuration>):

<configuration>
  <connectionStrings>
    <add name="MyMembershipConnString" 
    	connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnetdb;Integrated Security=True"/>
  </connectionStrings>
  
  <!-- ... -->
</configuration>

После настройки строки соединения с хранилищем данных о членстве понадобится сконфигурировать поставщик членства для приложения. Для этого необходимо добавить в файл web.config раздел <membership> (если его еще там нет) непосредственно внутри раздела <system.web>, как показано ниже (опять-таки, в корневом файле web.config, как описано в начале этого раздела - эмпирическое правило заключается в том, что эти конфигурации поставщика помещаются в корневой web.config, поскольку затрагивают все веб-приложение):

<configuration>
    <system.web>
      <membership defaultProvider="MyMembershipProvider">
        <providers>
          <add name="MyMembershipProvider"
               connectionStringName="MyMembershipConnString"
               type="System.Web.Security.SqlMembershipProvider"
               passwordFormat="Hashed"/>
        </providers>
      </membership>
    </system.web>
</configuration>

Внутри раздела <membership> можно добавить множество поставщиков как дочерние элементы раздела <providers>. В предыдущем коде показана допустимая конфигурация для поставщика SqlMembershipProvider. Важно не забыть об атрибуте defaultProvider. Этот атрибут указывает поставщика членства, который будет использоваться в коде.

Настроенные поставщики отображаются в веб-конфигурации ASP.NET при выборе переключателя Select a Different Provider for Each Feature (Выберите поставщика для каждой функции) в конфигурации поставщика. Это позволит выбирать отдельного поставщика для каждого средства, как показано на рисунке ниже:

Сконфигурированные поставщики, выбранные в WAT

В таблице ниже описаны наиболее важные свойства класса SqlMembershipProvider:

Свойства SqlMembershipProvider
Свойство Описание
Name

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

applicationName

Строковое значение, указывающее имя приложения, для которого поставщик членства управляет пользователями и их настройками. Это свойство позволяет использовать одну базу данных членства для множества приложений. Пользователи и роли всегда ассоциированы с приложением. Если имя приложения не указано, автоматически применяется корневое имя "/"

description

Необязательное описание поставщика членства

passwordFormat

Получает или устанавливает формат, в котором будут сохраняться пароли в хранилище удостоверений. Допустимые варианты: Clear - для хранения паролей в виде простого текста, Encrypted - для шифрования паролей в хранилище (для шифрования применяется локально настроенный ключ машины) и Hash - для хеширования паролей в хранилище информации о членстве

minRequiredNonAlphanumericCharacters

Указывает количество не алфавитно-цифровых символов, которые должен иметь пароль. Это важная часть проверки паролей, позволяющая указать требования к надежности паролей, выбираемых пользователями (по умолчанию 1)

minRequiredPasswordLength

Позволяет задать минимальную длину паролей для пользователей приложения. Это также важное свойство, определяющее надежность пароля (по умолчанию 7)

passwordStrengthRegularExpression

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

enablePasswordReset

Платформа Membership API имеет функциональность для переустановки пользовательских паролей и необязательной отправки электронной почты, если для приложения сконфигурирован SMTP-сервер

enablePasswordRetrieval

Когда установлено в true, можно извлекать пароль из объекта MembershipUser, вызывая его метод GetPassword(). Разумеется, это работает только тогда, когда пароль не хеширован

maxInvalidPasswordAttempts

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

passwordAttemptWindow

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

requiresQuestionAndAnswer

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

requiresUniqueEmail

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

После настройки хранилища данных и поставщика членства полученную конфигурацию можно использовать в приложении или, например, для создания пользователей в WAT. И здесь следует иметь в виду одно важное обстоятельство - эффект от свойства applicationName конфигурации членства. Благодаря этому свойству, можно использовать одну базу данных поставщика членства для более чем одного приложения. Каждый пользователь, роль, профиль - в действительности любой объект в базе данных членства - подключается к записи о приложении. Если не указать свойство applicationName в конфигурации членства, то Membership API (и, таким образом, любой административный инструмент, подобный WAT) ассоциирует объекты с корневым приложением по имени "/".

Если свойство applicationName в конфигурации поставщика членства установлено, то любой объект, созданный Membership API, будет ассоциирован с приложением, имя которого указано в этом свойстве.

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

Создание аутентифицируемых пользователей

Для создания новых пользователей в ранее созданном хранилище членства запустите WAT, выбрав в меню Website (Веб-сайт) пункт ASP.NET Web Configuration (Веб-конфигурирование ASP.NET) в среде Visual Studio. Перейдите на вкладку Security (Безопасность) и щелкните на ссылке Create User (Создать пользователя), как показано на рисунке ниже:

Создание пользователей в WAT

Как только несколько пользователей созданы, к базе данных можно подключиться через проводник Server Explorer в Visual Studio (что потребует добавления в Server Explorer подключения к базе данных членства) или с помощью SQL Server Management Studio и просмотреть таблицы aspnet_Users и aspnet_Membership:

Таблица aspnet_Users в базе данных членства

Как пароль, так и ответ на вопрос для восстановления пароля сохраняются базе данных в хешированном виде, поскольку в разделе конфигурации <membership> для поставщика была указана опция passwordFormat="Hashed", Это можно видеть при открытии таблицы aspnet_Membership, в которой хранятся эти значения:

Таблица aspnet_Membership с хешированным паролем и начальными значениями

После добавления пользователей к хранилищу информации о членстве их можно аутентифицировать с помощью Membership API. Для этой цели потребуется создать страницу входа, которая запрашивает у пользователя его имя и пароль, а затем проверяет эти данные по хранилищу удостоверений (в моем случае страница MyLogin.aspx, которую мы создали в статье «Реализация аутентификации с помощью форм»):

protected void LoginAction_Click(object sender, EventArgs e)
{
        Page.Validate();
        if (!Page.IsValid) return;
        
        if (Membership.ValidateUser(UsernameText.Text, PasswordText.Text))
        {
            FormsAuthentication.RedirectFromLoginPage(UsernameText.Text, false);
        }
        else
        {
            // Имя или пароль пользователя неправильны
            LegendStatus.Text = "Вы неправильно ввели имя пользователя или пароль!";
        }
}

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

Если вы тестируете сайт на полной версии IIS то при запуске этого примера может возникнуть ошибка "Cannot open database "aspnetdb" requested by the login. The login failed. Login failed for user 'IIS APPPOOL\DefaultAppPool'". Это связано с тем, что применяемый в IIS пул приложений, используемый по умолчанию, не ассоциирован с SQL Server Express. т.е. чтобы это сделать нужно изменить удостоверение пользователя пула. Для этого в IIS Manager откройте раздел "Пулы приложений", выберите необходимый пул (в моем случае это DefaultAppPool), щелкните по нему правой кнопкой мыши и в контекстном меню выберите "Дополнительные параметры". В открывшемся диалоговом окне измените параметр Удостоверение на Loacal System:

Настройка пула приложений IIS для допуска SQL Server

После этого пул приложений будет использовать локального пользователя NT AUTHORITY, у которого есть доступ к SQL Server Express. Для этого пользователя нужно будет открыть расширенные права доступа, для этого откройте SQL Server Management Studio, откройте раздел Security --> Logins и для пользователя выберите в контекстном меню Properties. В разделе Server Roles установите допуск sysadmin:

Допуск пользователя к SQL Server

Если вы тестируете сайт на встроенном в Visual Studio сервере IIS Express беспокоиться об этих деталях не нужно.

Пройди тесты