Общие сведения о проверке подлинности с помощью форм (C#)

Скотт Митчелл

Замечание

С момента написания этой статьи, поставщики членства ASP.NET были заменены на ASP.NET Identity. Настоятельно рекомендуется обновлять приложения для использования платформы ASP.NET Identity вместо поставщиков членства, которые использовались на момент написания этой статьи. ASP.NET Identity имеет ряд преимуществ по сравнению с системой членства ASP.NET, в том числе:

• Улучшенная производительность
• Улучшенная расширяемость и возможность тестирования
• Поддержка OAuth, OpenID Connect и двухфакторной проверки подлинности
• Поддержка идентификации на основе утверждений
• Улучшение взаимодействия с ASP.Net Core

Скачать код или Скачать PDF

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

Пожалуйста, посмотрите это видео для получения дополнительной информации по этой теме: Использование базовой аутентификации с помощью форм в ASP.NET.

Введение

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

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

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

Общие сведения о рабочем процессе аутентификации с помощью форм

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

HTTP-модули — это управляемые классы, код которых выполняется в ответ на определенное событие в жизненном цикле запроса. ASP.NET поставляется с рядом модулей HTTP, которые выполняют важные задачи в фоновом режиме. Два встроенных модуля HTTP, которые особенно важны для нашего обсуждения:

• FormsAuthenticationModule – Аутентифицирует пользователя путем проверки Forms Authentication Ticket, который обычно входит в коллекцию файлов cookie пользователя. Если билет проверки подлинности форм отсутствует, пользователь является анонимным.
• UrlAuthorizationModule – определяет, авторизован ли текущий пользователь для доступа к запрашиваемому URL-адресу. Этот модуль определяет полномочия путем сверки с правилами авторизации, указанными в конфигурационных файлах приложения. ASP.NET также включает в себя то FileAuthorizationModule , что определяет полномочия путем сверки с запрошенными файлами и списками управления доступом.

Попытки FormsAuthenticationModule аутентификации пользователя перед UrlAuthorizationModule (и FileAuthorizationModule) выполнением. Если пользователь, выполняющий запрос, не авторизован для доступа к запрашиваемому ресурсу, модуль авторизации завершает запрос и возвращает статус HTTP 401 Unauthorized . В сценариях проверки подлинности Windows браузеру возвращается состояние HTTP 401. Этот код состояния заставляет браузер запрашивать у пользователя учетные данные через модальное диалоговое окно. Однако при проверке подлинности с помощью форм статус HTTP 401 Unauthorized никогда не передается браузеру, потому что модуль FormsAuthenticationModule обнаруживает этот статус и изменяет его, чтобы перенаправить пользователя на страницу входа (через статус HTTP 302 Redirect ).

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

Рисунок 1: Рабочий процесс аутентификации с помощью форм

Запоминание билета аутентификации при каждом посещении страницы

После входа в систему билет аутентификации форм должен отправляться обратно на веб-сервер при каждом запросе, чтобы пользователь оставался в системе во время просмотра сайта. Обычно это достигается путем помещения билета аутентификации в коллекцию файлов cookie пользователя. Файлы cookie — это небольшие текстовые файлы, которые находятся на компьютере пользователя и передаются в заголовках HTTP при каждом запросе к веб-сайту, создавшему файл cookie. Таким образом, после того, как билет аутентификации с помощью форм был создан и сохранен в файлах cookie браузера, при каждом последующем посещении этого сайта билет аутентификации отправляется вместе с запросом, тем самым идентифицируя пользователя.

Одним из аспектов файлов cookie является их истечение срока действия, то есть дата и время, когда браузер удаляет файл cookie. Когда срок действия файла cookie для аутентификации форм истекает, пользователь больше не может проходить аутентификацию и, следовательно, становится анонимным. Когда пользователь заходит на сайт с общедоступного терминала, скорее всего, он захочет, чтобы срок его билета аутентификации истек при закрытии браузера. Однако при посещении из дома тот же пользователь может захотеть, чтобы билет аутентификации запоминался при перезапуске браузера, чтобы ему не приходилось повторно входить в систему при каждом посещении сайта. Это решение часто принимается пользователем в виде галочки «Запомнить меня» на странице входа. На шаге 3 мы рассмотрим, как реализовать флажок «Запомнить меня» на странице входа в систему. В следующем руководстве подробно рассматриваются настройки времени ожидания билета проверки подлинности.

Замечание

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

Область применения аутентификации с помощью форм

Это FormsAuthenticationModule управляемый код, который является частью среды выполнения ASP.NET. До появления версии 7 веб-сервера Internet Information Services (IIS) корпорации Майкрософт существовал явный барьер между конвейером HTTP IIS и конвейером среды выполнения ASP.NET. Короче говоря, в IIS 6 и более ранних версиях выполняется FormsAuthenticationModule только тогда, когда запрос делегирован из IIS в ASP.NET среду выполнения. По умолчанию IIS сам обрабатывает статическое содержимое, такое как HTML-страницы, файлы CSS и изображений, и передает запросы к среде выполнения ASP.NET только при запросе страницы с расширением .aspx, .asmx или .ashx.

Тем не менее, IIS 7 позволяет использовать интегрированные конвейеры IIS и ASP.NET. С помощью нескольких параметров конфигурации можно настроить IIS 7 на вызов модуля FormsAuthenticationModule для всех запросов. Кроме того, с помощью IIS 7 можно определить правила авторизации URL-адресов для файлов любого типа. Дополнительные сведения см. в разделах Изменения между безопасностью IIS6 и IIS7, Безопасность веб-платформы и Общие сведения об авторизации URL-адресов IIS7.

Короче говоря, в версиях, предшествующих IIS 7, вы можете использовать аутентификацию с помощью форм только для защиты ресурсов, обрабатываемых средой выполнения ASP.NET. Аналогичным образом, правила авторизации URL-адресов применяются только к ресурсам, обрабатываемым средой выполнения ASP.NET. Но с помощью IIS 7 можно интегрировать FormsAuthenticationModule и UrlAuthorizationModule в конвейер HTTP IIS, тем самым распространяя эту функциональность на все запросы.

Шаг 1: Создание ASP.NET сайта для этой серии уроков

Чтобы охватить как можно более широкую аудиторию, ASP.NET веб-сайт, который мы будем создавать в этой серии, будет создан с помощью бесплатной версии Visual Studio 2008 от Microsoft, Visual Web Developer 2008. Мы реализуем пользовательское хранилище SqlMembershipProvider в базе данных Microsoft SQL Server 2005 Express Edition . Если вы используете Visual Studio 2005 или другую версию Visual Studio 2008 или SQL Server, не беспокойтесь - шаги будут почти идентичными, а любые нетривиальные различия будут указаны.

Замечание

Демонстрационное веб-приложение, используемое в каждом уроке, доступно для загрузки. Это загружаемое приложение было создано с помощью Visual Web Developer 2008, предназначенного для .NET Framework версии 3.5. Поскольку приложение предназначено для .NET 3.5, его Web.config файл содержит дополнительные, специфичные для версии 3.5 элементы конфигурации. Короче говоря, если вы еще не установили .NET 3.5 на свой компьютер, то загружаемое веб-приложение не будет работать без предварительного удаления разметки, специфичной для версии 3.5, из Web.config.

Прежде чем мы сможем настроить аутентификацию с помощью форм, нам сначала понадобится веб-сайт ASP.NET. Начните с создания нового веб-сайта ASP.NET на основе файловой системы. Для этого запустите Visual Web Developer, а затем перейдите в меню «Файл» и выберите «Новый веб-сайт», отобразив диалоговое окно «Новый веб-сайт». Выберите шаблон веб-сайта ASP.NET, установите раскрывающийся список "Расположение" в файловой системе, выберите папку для размещения веб-сайта и задайте язык на C#. В результате будет создан новый веб-сайт со страницей Default.aspx ASP.NET, папкой App_Data и файлом Web.config.

Замечание

Visual Studio поддерживает два режима управления проектами: проекты веб-сайтов и проекты веб-приложений. В проектах веб-сайтов отсутствует файл проекта, в то время как в проектах веб-приложений имитируется архитектура проекта в Visual Studio .NET 2002/2003 — они включают файл проекта и компилируют исходный код проекта в единую сборку, которая помещается в папку /bin. Visual Studio 2005 первоначально поддерживала только проекты веб-сайтов, хотя модель проектов веб-приложений была вновь введена в Service Pack 1; Visual Studio 2008 предлагает обе модели проекта. Однако редакции Visual Web Developer 2005 и 2008 поддерживают только проекты веб-сайтов. Я буду использовать модель проекта веб-сайта. Если вы используете версию, отличную от Express, и хотите использовать вместо нее модель Web Application Project , не стесняйтесь делать это, но имейте в виду, что могут быть некоторые расхождения между тем, что вы видите на экране, и шагами, которые вы должны предпринять, и показанными снимками экрана и инструкциями, предоставленными в этих руководствах.

Рисунок 2: Создание нового файла System-Based веб-сайте (Нажмите, чтобы просмотреть полноразмерное изображение)

Добавление страницы-шаблона

Затем добавьте новую главную страницу на сайт в корневом каталоге с именем Site.master. Главные страницы позволяют разработчику страницы определить шаблон для всего сайта, который может быть применен к ASP.NET страницам. Основное преимущество мастер-страниц заключается в том, что общий внешний вид сайта может быть определен в одном месте, что упрощает обновление или настройку макета сайта.

Рисунок 3: Добавьте мастер-страницу с именем Site.master на сайт (Нажмите, чтобы просмотреть полноразмерное изображение)

Определите макет страницы на уровне сайта на главной странице. Вы можете использовать дизайнерский режим и добавить нужные элементы макета или веб-элементы управления, либо вручную добавить HTML-разметку в режиме исходного кода. Я структурировал макет страницы-шаблона таким образом, чтобы имитировать макет, используемый в серии учебников « Работа с данными в ASP.NET версии 2.0 » (см. рис. 4). Главная страница использует каскадные таблицы стилей для позиционирования и стилей с параметрами CSS, определенными в файле Style.css (который включен в связанную с этим учебником загрузку). Хотя вы не можете этого понять по разметке, показанной ниже, правила CSS определены таким образом, что содержимое навигационного <div> абсолютно расположено так, чтобы оно отображалось слева и имело фиксированную ширину 200 пикселей.

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="Site.master.cs" Inherits="Site" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Forms Authentication, Authorization, and User Accounts</title>
    <link href="Styles.css" rel="stylesheet" type="text/css" />
</head>
<body>
    <div id="wrapper">
        <form id="form1" runat="server">
        
            <div id="header">
                <span class="title">User Account Tutorials</span>
            </div>
        
            <div id="content">
                <asp:contentplaceholder id="MainContent" runat="server">
                  <!-- Page-specific content will go here... -->
                </asp:contentplaceholder>
            </div>
            
            <div id="navigation">
                TODO: Menu will go here...
            </div>
        </form>
    </div>
</body>
</html>

Эталонная страница определяет как статический макет страницы, так и регионы, которые можно изменить на страницах ASP.NET, использующих главную страницу. Эти редактируемые области содержимого обозначаются ContentPlaceHolder элементом управления, который можно увидеть в div< содержимого>. Наша главная страница имеет один ContentPlaceHolder (MainContent), но мастер-страницы могут иметь несколько ContentPlaceHolders.

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

Рис. 4. Эталонная страница при просмотре в режиме конструктора (щелкните, чтобы просмотреть изображение полного размера)

Создание страниц с контентом

На данный момент у нас есть страница Default.aspx на нашем веб-сайте, но она не использует главную страницу, которую мы только что создали. Хотя можно манипулировать декларативной разметкой веб-страницы для использования главной страницы, если страница еще не содержит никакого контента, проще просто удалить страницу и снова добавить ее в проект, указав главную страницу для использования. Поэтому начните с удаления Default.aspx из проекта.

Затем щелкните правой кнопкой мыши имя проекта в обозревателе решений и выберите добавление новой веб-формы с именем Default.aspx. На этот раз поставьте галочку "Выбрать мастер-страницу" и выберите мастер-страницу Site.master из списка.

Рисунок 5: Добавьте новую страницу Default.aspx выбрав главную страницу (Нажмите, чтобы просмотреть полноразмерное изображение)

Рисунок 6: Использование мастер-страницы Site.master

Замечание

Если используется модель проекта веб-приложения, в диалоговом окне "Добавить новый элемент" отсутствует флажок "Выбрать главную страницу". Вместо этого необходимо добавить элемент типа "Web Content Form". После выбора опции "Web Content Form" и нажатия кнопки Add, Visual Studio отобразит то же диалоговое окно "Выбор мастера", показанное на рисунке 6.

Декларативная разметка новой страницы Default.aspx включает только директиву @Page , указывающую путь к файлу главной страницы, и элемент управления Content для MainContent ContentPlaceHolder главной страницы.

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
</asp:Content>

А пока оставьте Default.aspx пустым. Мы вернемся к нему позже в этом уроке, чтобы добавить контент.

Замечание

Наша мастер-страница включает в себя раздел для меню или другого навигационного интерфейса. Мы создадим такой интерфейс в одном из следующих уроков.

Шаг 2: Включение аутентификации с помощью форм

После создания ASP.NET сайта нашей следующей задачей будет включение аутентификации форм. Конфигурация аутентификации приложения задается с помощью <authentication> элемента в Web.config. Элемент <authentication> содержит один атрибут mode, который указывает модель аутентификации, используемую приложением. Этот атрибут может иметь одно из следующих четырех значений:

• Windows – как обсуждалось в предыдущем руководстве, когда приложение использует проверку подлинности Windows, веб-сервер отвечает за проверку подлинности посетителя, и обычно это делается с помощью базовой, дайджестовой или интегрированной проверки подлинности Windows.
• Формы – пользователи аутентифицируются с помощью формы на веб-странице.
• Passport – пользователи проходят проверку подлинности с помощью Microsoft Passport Network.
• None– модель аутентификации не используется; Все посетители анонимны.

По умолчанию ASP.NET приложения используют проверку подлинности Windows. Чтобы изменить тип аутентификации на аутентификацию по формам, нам нужно изменить <authentication> атрибут mode элемента на Forms.

Если ваш проект еще не содержит файл Web.config, добавьте его сейчас, щелкнув правой кнопкой мыши имя проекта в обозревателе решений, выбрав «Добавить новый элемент», а затем добавив файл веб-конфигурации.

Рисунок 7: Если ваш проект еще не включает Web.config, добавьте его сейчас (Нажмите, чтобы просмотреть изображение в полном размере)

Затем найдите <authentication> элемент и обновите его, чтобы использовать аутентификацию с помощью форм. После этого изменения разметка файла Web.config должна выглядеть следующим образом:

<configuration>
    <system.web>
        ... Unrelated configuration settings and comments removed for brevity ...
        <!--
            The <authentication> section enables configuration 
            of the security authentication mode used by 
            ASP.NET to identify an incoming user. 
        -->
        <authentication mode="Forms" />
    </system.web>
</configuration>

Замечание

Поскольку Web.config является XML-файлом, регистр важен. Убедитесь, что вы установили для атрибута mode значение Forms с заглавной буквы "F". Если вы используете другой регистр, например «формы», вы получите ошибку конфигурации при переходе на сайт через браузер.

При необходимости элемент <authentication> может включать дочерний <forms> элемент, содержащий настройки, специфичные для аутентификации форм. На данный момент давайте просто воспользуемся настройками аутентификации форм по умолчанию. Более подробно мы рассмотрим дочерний <forms> элемент в следующем уроке.

Шаг 3: Создание страницы входа в систему

Для поддержки аутентификации с помощью форм нашему сайту нужна страница входа в систему. Как обсуждалось в разделе «Общие сведения о рабочем процессе аутентификации с помощью форм», пользователь FormsAuthenticationModule автоматически перенаправляется на страницу входа, если он пытается получить доступ к странице, на просмотр которой у него нет авторских прав. Существуют также ASP.NET веб-элементы управления, которые будут отображать ссылку на страницу входа для анонимных пользователей. В связи с этим возникает вопрос: «Каков URL-адрес страницы входа в систему?»

По умолчанию система аутентификации форм ожидает, что страница входа будет названа Login.aspx и помещена в корневой каталог веб-приложения. Если вы хотите использовать другой URL-адрес страницы входа, вы можете сделать это, указав его в Web.config. Как это сделать, мы увидим в следующем уроке.

У страницы входа в систему есть три обязанности:

1. Предоставьте интерфейс, позволяющий посетителю вводить свои учетные данные.
2. Определите, действительны ли отправленные учетные данные.
3. «Авторизуйтесь» в аккаунте пользователя, создав билет для аутентификации с помощью форм.

Создание пользовательского интерфейса страницы входа

Приступим к выполнению первой задачи. Добавьте новую страницу ASP.NET в корневой каталог сайта с именем Login.aspx и свяжите ее с главной страницей Site.master.

Рисунок 8: Добавьте новую страницу ASP.NET с именем Login.aspx (Нажмите, чтобы просмотреть полноразмерное изображение)

Типичный интерфейс страницы входа состоит из двух текстовых полей — одно для имени пользователя, одно для пароля — и кнопки для отправки формы. На веб-сайтах часто есть флажок «Запомнить меня», который, если он установлен, сохраняет полученный билет аутентификации при перезагрузке браузера.

Добавьте два текстовых поля в Login.aspx и задайте для них ID свойства UserName и Password соответственно. Также установите свойство TextMode Password в значение Password. Затем добавьте элемент управления CheckBox, установив для его ID свойства значение RememberMe, а Text для свойства — значение "Remember Me". После этого добавьте кнопку с именем LoginButton, свойство которой Text установлено в значение "Login". И, наконец, добавьте веб-элемент управления Label и задайте для его ID свойства значение InvalidCredentialsMessage, а для свойства Text — значение "Ваше имя пользователя или пароль недопустимы. Пожалуйста, повторите попытку.", его ForeColor свойство имеет значение Red, а свойство Visible - False.

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

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <h1>
        Login</h1>
    <p>
        Username:
        <asp:TextBox ID="UserName" runat="server"></asp:TextBox></p>
    <p>
        Password:
        <asp:TextBox ID="Password" runat="server" TextMode="Password"></asp:TextBox></p>
    <p>
        <asp:CheckBox ID="RememberMe" runat="server" Text="Remember Me" /> </p>
    <p>
        <asp:Button ID="LoginButton" runat="server" Text="Login" OnClick="LoginButton_Click" /> </p>
    <p>
        <asp:Label ID="InvalidCredentialsMessage" runat="server" ForeColor="Red" Text="Your username or password is invalid. Please try again."
            Visible="False"></asp:Label> </p>
</asp:Content>

Рисунок 9: Страница входа содержит два текстовых поля, чекбокс, кнопку и метку (нажмите, чтобы просмотреть полноразмерное изображение)

Наконец, создайте обработчик событий для события Click LoginButton. В конструкторе просто дважды щелкните элемент управления Button, чтобы создать этот обработчик событий.

Определение действительности предоставленных учетных данных

Теперь нам нужно реализовать задачу 2 в обработчике событий Button Click — определить, действительны ли предоставленные учетные данные. Для этого необходимо создать хранилище пользователей, в котором хранятся все учетные данные пользователей, чтобы мы могли определить, совпадают ли предоставленные учетные данные с какими-либо известными учетными данными.

До ASP.NET 2.0 разработчики отвечали как за реализацию собственных пользовательских хранилищ, так и за написание кода для проверки предоставленных учетных данных в хранилище. Большинство разработчиков реализуют хранилище пользователей в базе данных, создавая таблицу с именем Users со столбцами типа UserName, Password, Email, LastLoginDate и т. д. Таким образом, в этой таблице будет одна запись для каждой учетной записи пользователя. Проверка предоставленных пользователем учетных данных включает в себя запрос в базу данных на предмет совпадения имени пользователя, а затем проверку соответствия пароля в базе данных предоставленному паролю.

В ASP.NET 2.0 разработчики должны использовать одного из поставщиков членства для управления пользовательским хранилищем. В этой серии уроков мы будем использовать SqlMembershipProvider, который использует базу данных SQL Server для пользовательского хранилища. При использовании SqlMembershipProvider нам необходимо реализовать определенную схему базы данных, которая включает в себя таблицы, представления и хранимые процедуры, ожидаемые поставщиком. Мы рассмотрим, как реализовать эту схему, в учебнике по созданию схемы членства в SQL Server . При наличии поставщика членства проверка учетных данных пользователя сводится к вызову метода ValidateUser(username, password)класса членства, который возвращает логическое значение, указывающее на действительность комбинации имени пользователя и пароля. Поскольку мы еще не реализовали хранилище пользователей SqlMembershipProvider, в настоящее время мы не можем использовать метод ValidateUser класса Membership.

Вместо того чтобы тратить время на создание собственной пользовательской таблицы базы данных Users (которая устарела бы после того, как мы внедрили SqlMembershipProvider), давайте жестко запрограммируем действительные учетные данные на самой странице входа. В обработчике события Click LoginButton добавьте следующий код:

protected void LoginButton_Click(object sender, EventArgs e)
{
    // Three valid username/password pairs: Scott/password, Jisun/password, and Sam/password.
    string[] users = { "Scott", "Jisun", "Sam" };
    string[] passwords = { "password", "password", "password" };
    for (int i = 0; i < users.Length; i++)
    {
        bool validUsername = (string.Compare(UserName.Text, users[i], true) == 0);
        bool validPassword = (string.Compare(Password.Text, passwords[i], false) == 0);
        if (validUsername && validPassword)
        {
            // TODO: Log in the user...
            // TODO: Redirect them to the appropriate page
        }
    }
    // If we reach here, the user's credentials were invalid
    InvalidCredentialsMessage.Visible = true;
}

Как вы можете видеть, есть три действительные учетные записи пользователей — Скотт, Джисун и Сэм — и все три имеют один и тот же пароль («пароль»). Код перебирает массивы пользователей и паролей в поисках действительного совпадения имени пользователя и пароля. Если и логин, и пароль действительны, нам нужно авторизовать пользователя, а затем перенаправить его на соответствующую страницу. Если учетные данные недействительны, мы отображаем метку InvalidCredentialsMessage.

Когда пользователь вводит действительные учетные данные, я упоминал, что он затем перенаправляется на «соответствующую страницу». Но какая страница подходит? Помните, что когда пользователь посещает страницу, на просмотр которой у него нет прав, модуль FormsAuthenticationModule автоматически перенаправляет его на страницу входа. При этом он включает запрошенный URL-адрес в строку запроса с помощью параметра ReturnUrl. То есть, если пользователь попытался посетить ProtectedPage.aspx и у него не было на это разрешения, FormsAuthenticationModule перенаправит его на:

Login.aspx? ReturnUrl=ProtectedPage.aspx

После успешного входа в систему пользователь должен быть перенаправлен обратно в ProtectedPage.aspx. Кроме того, пользователи могут посетить страницу входа в систему по своему усмотрению. В этом случае, после входа пользователя в систему, они должны быть отправлены на Default.aspx страницу корневой папки.

Вход в систему пользователя

Предполагая, что предоставленные учетные данные действительны, нам нужно создать билет аутентификации формы, тем самым авторизуя пользователя на сайте. Класс FormsAuthentication в пространстве имен System.Web.Security предоставляет различные методы для входа и выхода пользователей через систему проверки подлинности форм. Несмотря на то, что в классе FormsAuthentication есть несколько методов, на данном этапе нас интересуют следующие три:

• GetAuthCookie(username, persistCookie) – создает билет аутентификации формы для предоставленного имени пользователя. Затем этот метод создает и возвращает объект HttpCookie, который содержит содержимое билета проверки подлинности. Если persistCookie имеет значение true, создается постоянный файл cookie.
• SetAuthCookie(username, persistCookie) – вызывает метод GetAuthCookie(username, persistCookie) для генерации cookie аутентификации форм. Затем этот метод добавляет файл cookie, возвращенный GetAuthCookie, в коллекцию Cookies (при условии, что используется аутентификация на основе форм cookie; в противном случае этот метод вызывает внутренний класс, который обрабатывает логику билетов без файлов cookie).
• RedirectFromLoginPage(username, persistCookie) – этот метод вызывает SetAuthCookie(username, persistCookie), а затем перенаправляет пользователя на соответствующую страницу.

GetAuthCookie удобен, когда вам нужно изменить билет аутентификации перед записью файла cookie в коллекцию файлов cookie. SetAuthCookie полезен, если вы хотите создать билет проверки подлинности форм и добавить его в коллекцию Cookies, но не хотите перенаправлять пользователя на соответствующую страницу. Возможно, вы хотите оставить их на странице входа в систему или отправить на какую-то альтернативную страницу.

Так как мы хотим авторизовать пользователя и перенаправить его на соответствующую страницу, давайте воспользуемся RedirectFromLoginPage. Обновите обработчик события Click в LoginButton, заменив две закомментированные строки TODO следующей строкой кода:

FormsAuthentication.RedirectFromLoginPage(UserName.Text, RememberMe.Checked);

При создании билета аутентификации с помощью форм мы используем свойство Text TextBox UserName для параметра username билета аутентификации по формам и проверенное состояние RememberMe CheckBox для параметра persistCookie .

Чтобы протестировать страницу входа, перейдите на нее в браузере. Начните с ввода недействительных учетных данных, таких как имя пользователя "Nope" и пароль "wrong". При нажатии на кнопку «Войти» произойдет обратная передача и отобразится метка InvalidCredentialsMessage.

Рисунок 10: Метка InvalidCredentialsMessage отображается при вводе недействительных учетных данных (Нажмите, чтобы просмотреть изображение в полном размере)

Далее введите действительные учетные данные и нажмите кнопку «Войти». На этот раз, когда происходит постбэк, создается билет аутентификации форм, и вы автоматически перенаправляетесь обратно в Default.aspx. На этом этапе вы вошли на веб-сайт, хотя нет никаких визуальных подсказок, указывающих на то, что вы в данный момент вошли в систему. На шаге 4 мы увидим, как программно определить, вошел пользователь в систему или нет, а также как идентифицировать пользователя, посетившего страницу.

На шаге 5 рассматриваются методы выхода пользователя из системы.

Защита страницы входа в систему

Когда пользователь вводит свои учетные данные и отправляет форму на странице входа, учетные данные, включая пароль, передаются через Интернет на веб-сервер в виде обычного текста. Это означает, что любой хакер, прослушивающий сетевой трафик, может увидеть имя пользователя и пароль. Чтобы предотвратить это, важно зашифровать сетевой трафик с помощью Secure Socket Layers (SSL). Это гарантирует, что учетные данные (а также HTML-разметка всей страницы) будут зашифрованы с момента их выхода из браузера до их получения веб-сервером.

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

Замечание

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

Шаг 4: Обнаружение аутентифицированных посетителей и определение их личности

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

Давайте дополним существующую страницу Default.aspx, чтобы проиллюстрировать эти методы. В Default.aspx добавьте два элемента управления Panel, один с именем AuthenticatedMessagePanel, а другой с именем AnonymousMessagePanel. Добавьте элемент управления Label с именем WelcomeBackMessage на первой панели. На второй панели добавьте элемент управления HyperLink, установите его свойство Text на "Log In" и свойство NavigateUrl на "~/Login.aspx". На этом этапе заявительная разметка для Default.aspx должна выглядеть примерно так:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <asp:Panel runat="server" ID="AuthenticatedMessagePanel">
        <asp:Label runat="server" ID="WelcomeBackMessage"></asp:Label>
    </asp:Panel>
    
    <asp:Panel runat="Server" ID="AnonymousMessagePanel">
        <asp:HyperLink runat="server" ID="lnkLogin" Text="Log In" NavigateUrl="~/Login.aspx"></asp:HyperLink>
    </asp:Panel>
</asp:Content>

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

Свойство Request.IsAuthenticated возвращает логическое значение, указывающее, была ли проверка подлинности запроса. Введите следующий код в код обработчика событий Page_Load:

protected void Page_Load(object sender, EventArgs e)
{
    if (Request.IsAuthenticated)
    {
        WelcomeBackMessage.Text = "Welcome back!";
    
        AuthenticatedMessagePanel.Visible = true;
        AnonymousMessagePanel.Visible = false;
    }
    else
    {
        AuthenticatedMessagePanel.Visible = false;
        AnonymousMessagePanel.Visible = true;
    }
}

Имея этот код, посетите Default.aspx через браузер. Предполагая, что вы еще не вошли в систему, вы увидите ссылку на страницу входа (см. рисунок 11). Перейдите по этой ссылке и авторизуйтесь на сайте. Как мы видели на шаге 3, после ввода учетных данных вы вернетесь в Default.aspx, но на этот раз на странице отображается сообщение «С возвращением!» (см. рисунок 12).

Рисунок 11: При анонимном посещении отображается ссылка для входа в систему

Рисунок 12: Аутентифицированным пользователям показывается надпись "Добро пожаловать!" Сообщение

Мы можем определить личность текущего вошедшего в систему пользователя с помощью свойства Userобъекта HttpContext. Объект HttpContext представляет информацию о текущем запросе и является домом для таких общих объектов ASP.NET, как Response, Request и Session, среди прочих. Свойство User представляет контекст безопасности текущего HTTP-запроса и реализует интерфейс IPrincipal.

Свойство User задается модулем FormsAuthenticationModule. В частности, когда FormsAuthenticationModule находит билет проверки подлинности форм во входящем запросе, он создает новый объект GenericPrincipal и присваивает его свойству User.

Объекты Principal (например, GenericPrincipal) предоставляют информацию об удостоверении пользователя и ролях, к которым он принадлежит. Интерфейс IPrincipal определяет два элемента:

• IsInRole(roleName) – метод, который возвращает логическое значение, указывающее, принадлежит ли участник к указанной роли.
• Identity – свойство, которое возвращает объект, реализующий интерфейс IIdentity. Интерфейс IIdentity определяет три свойства: AuthenticationType, IsAuthenticated и Name.

Мы можем определить имя текущего посетителя с помощью следующего кода:

string currentUsersName = User.Identity.Name;

При использовании проверки подлинности с помощью форм создается объект FormsIdentity для свойства Identity GenericPrincipal. Класс FormsIdentity всегда возвращает строку "Forms" для свойства AuthenticationType и true для свойства IsAuthenticated. Свойство Name возвращает имя пользователя, указанное при создании билета проверки подлинности форм. В дополнение к этим трем свойствам FormsIdentity включает доступ к базовому билету проверки подлинности через свойство Ticket. Свойство Ticket возвращает объект типа FormsAuthenticationTicket, который имеет такие свойства, как Expiration, IsPersistent, IssueDate, Name и т. д.

Здесь важно отметить, что параметр username , указанный в методах FormsAuthentication.GetAuthCookie(username, persistCookie), FormsAuthentication.SetAuthCookie(username, persistCookie) и FormsAuthentication.RedirectFromLoginPage(username, persistCookie), является тем же значением, которое возвращает User.Identity.Name. Более того, билет аутентификации, созданный этими методами, можно получить, приведя User.Identity к объекту FormsIdentity и обратившись к свойству Ticket:

FormsIdentity ident = User.Identity as FormsIdentity;
FormsAuthenticationTicket authTicket = ident.Ticket;

Давайте предоставим более персонализированное сообщение в Default.aspx. Обновите обработчик событий Page_Load, чтобы свойству Text метки WelcomeBackMessage была присвоена строка "С возвращением, имя пользователя!"

WelcomeBackMessage.Text = "С возвращением, " + User.Identity.Name + "!";

На рисунке 13 показан эффект этого изменения (при входе в систему под именем пользователя Scott).

Рисунок 13: Приветственное сообщение включает имя пользователя, вошедшего в систему

Использование элементов управления LoginView и LoginName

Отображение различного контента для аутентифицированных и анонимных пользователей является распространенным требованием; Как и отображение имени пользователя, вошедшего в систему в данный момент. По этой причине ASP.NET включает в себя два веб-элемента управления, которые предоставляют ту же функциональность, что и рисунок 13, но без необходимости написания единой строки кода.

Элемент управления LoginView — это веб-элемент управления на основе шаблонов, который упрощает отображение различных данных для аутентифицированных и анонимных пользователей. LoginView включает в себя два предопределенных шаблона:

• AnonymousTemplate – любая разметка, добавленная в этот шаблон, отображается только анонимным посетителям.
• LoggedInTemplate – разметка этого шаблона показывается только аутентифицированным пользователям.

Давайте добавим элемент управления LoginView на главную страницу нашего сайта, Site.master. Однако вместо того, чтобы добавлять только элемент управления LoginView, давайте добавим новый элемент управления ContentPlaceHolder, а затем поместим элемент управления LoginView в этот новый элемент управления ContentPlaceHolder. Обоснование этого решения станет очевидным в ближайшее время.

Замечание

В дополнение к AnonymousTemplate и LoggedInTemplate, элемент управления LoginView может включать шаблоны, специфичные для ролей. Шаблоны для конкретных ролей показывают разметку только тем пользователям, которые принадлежат к указанной роли. В одном из следующих учебников мы рассмотрим функции элемента управления LoginView, основанные на ролях.

Начните с добавления ContentPlaceHolder с именем LoginContent на главную страницу в элементе div< навигации>. Вы можете просто перетащить элемент управления ContentPlaceHolder с панели элементов на представление исходного кода, поместив полученную разметку прямо над надписью «TODO: Меню перейдет сюда...» СМС.

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Затем добавьте элемент управления LoginView в LoginContent ContentPlaceHolder. Содержимое, помещенное в элементы управления ContentPlaceHolder главной страницы, считается содержимым по умолчанию для ContentPlaceHolder. Это означает, что ASP.NET страницы, использующие эту главную страницу, могут указать собственное содержимое для каждого объекта ContentPlaceHolder или использовать содержимое главной страницы по умолчанию.

LoginView и другие элементы управления, связанные со входом в систему, находятся на вкладке «Вход» на панели инструментов.

Рисунок 14: Элемент управления LoginView на панели инструментов

Затем добавьте два <элемента br /> сразу после элемента управления LoginView, но все еще внутри ContentPlaceHolder. На этом этапе разметка элемента div <> навигации должна выглядеть следующим образом:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
        </asp:LoginView>
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Шаблоны LoginView могут быть определены в дизайнере или в декларативной разметке. В конструкторе Visual Studio разверните смарт-тег LoginView, в котором перечислены настроенные шаблоны в раскрывающемся списке. Введите текст "Hello, stranger" в AnonymousTemplate; Затем добавьте элемент управления HyperLink и задайте для его свойств Text и NavigateUrl значения "LogIn" и "~/Login.aspx" соответственно.

После настройки AnonymousTemplate переключитесь на LoggedInTemplate и введите текст "С возвращением, ". Затем перетащите элемент управления LoginName с панели элементов в шаблон LoggedInTemplate, поместив его сразу после текста "Welcome back,". Элемент управления LoginName, как следует из его названия, отображает имя пользователя, вошедшего в систему в данный момент. На внутреннем уровне элемент управления LoginName просто выводит свойство User.Identity.Name

После внесения этих дополнений в шаблоны LoginView, разметка должна выглядеть примерно так:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

С этим дополнением к главной странице Site.master на каждой странице нашего веб-сайта будет отображаться отдельное сообщение в зависимости от того, прошел ли пользователь проверку подлинности. На рисунке 15 показана Default.aspx страница при посещении через браузер пользователем Jisun. Сообщение «С возвращением, Jisun» повторяется дважды: один раз в разделе навигации главной страницы слева (через элемент управления LoginView, который мы только что добавили) и один раз в области содержимого Default.aspx (через элементы управления Panel и программную логику).

Рисунок 15: Элемент управления LoginView отображает "С возвращением, Jisun".

Поскольку мы добавили LoginView на главную страницу, он может отображаться на каждой странице нашего сайта. Однако могут быть веб-страницы, на которых мы не хотим показывать это сообщение. Одной из таких страниц является страница входа, так как ссылка на страницу входа там кажется неуместной. Поскольку мы поместили элемент управления LoginView в ContentPlaceHolder на главной странице, мы можем переопределить эту разметку по умолчанию на нашей странице содержимого. Откройте Login.aspx и перейдите в Дизайнер. Поскольку мы явно не определили элемент управления Content в Login.aspx для LoginContent ContentPlaceHolder на главной странице, на странице входа будет отображаться разметка главной страницы по умолчанию для этого ContentPlaceHolder. Вы можете увидеть это через дизайнер — LoginContent ContentPlaceHolder показывает разметку по умолчанию (элемент управления LoginView).

Рисунок 16: Страница входа показывает содержимое по умолчанию для LoginContent ContentPlaceHolder главной страницы (Нажмите, чтобы просмотреть полноразмерное изображение)

Чтобы переопределить разметку по умолчанию для LoginContent ContentPlaceHolder, просто щелкните правой кнопкой мыши область в дизайнере и выберите опцию Create Custom Content из контекстного меню. (При использовании Visual Studio 2008 ContentPlaceHolder включает смарт-тег, который при выборе предлагает ту же опцию.) Это добавляет новый элемент управления содержимым в разметку страницы и тем самым позволяет нам определить пользовательский контент для этой страницы. Вы могли бы добавить сюда пользовательское сообщение, например, «Пожалуйста, войдите...», но давайте просто оставим это поле пустым.

Замечание

В Visual Studio 2005 при создании пользовательского содержимого создается пустой элемент управления Content на ASP.NET странице. Однако в Visual Studio 2008 при создании пользовательского содержимого содержимое по умолчанию копируется содержимое главной страницы во вновь созданный элемент управления содержимым. Если вы используете Visual Studio 2008, то после создания нового элемента управления содержимым обязательно удалите содержимое, скопированное с главной страницы.

На рисунке 17 показана Login.aspx страница при посещении из браузера после внесения этого изменения. Обратите внимание, что в левом навигационном div< нет сообщения "Здравствуйте, незнакомец" или "С возвращением, >", как при посещении Default.aspx.

Рисунок 17: Страница входа скрывает разметку ContentPlaceHolder по умолчанию (Нажмите, чтобы просмотреть полноразмерное изображение)

Шаг 5: Выход из системы

На Шаге 3 мы рассмотрели создание страницы входа для входа пользователя на сайт, но нам еще предстоит увидеть, как выйти из системы. В дополнение к методам для входа пользователя в систему класс FormsAuthentication также предоставляет метод SignOut. Метод SignOut просто уничтожает билет проверки подлинности форм, тем самым выводя пользователя из сайта.

Предложение ссылки для выхода из системы является настолько распространенной функцией, что ASP.NET включает в себя элемент управления, специально разработанный для выхода пользователя из системы. Элемент управления LoginStatus отображает либо LinkButton "Login", либо LinkButton "Logout", в зависимости от состояния аутентификации пользователя. Кнопка LinkButton "Login" отображается для анонимных пользователей, в то время как кнопка LinkButton "Logout" отображается для аутентифицированных пользователей. Текст для кнопок ссылок "Login" и "Logout" можно настроить с помощью свойств LoginText и LogoutText в LoginStatus.

Нажатие на кнопку-ссылку «Войти» вызывает постбек, с которого выдается редирект на страницу входа. Нажатие кнопки LinkButton "Logout" приводит к тому, что элемент управления LoginStatus вызывает метод FormsAuthentication.SignOff, а затем перенаправляет пользователя на страницу. Страница, на которую будет перенаправлен вышедший из системы пользователь, зависит от свойства LogoutAction, которому может быть присвоено одно из трех следующих значений:

• Refresh – по умолчанию; перенаправляет пользователя на страницу, которую он только что посетил. Если страница, которую они только что посетили, не разрешает анонимных пользователей, то модуль FormsAuthenticationModule автоматически перенаправит пользователя на страницу входа.

Возможно, вам будет любопытно, почему здесь выполняется редирект. Если пользователь хочет оставаться на той же странице, зачем нужен явный редирект? Причина в том, что при нажатии кнопки «Logoff» у пользователя все еще есть билет аутентификации форм в его коллекции cookies. Следовательно, запрос postback является аутентифицированным запросом. Элемент управления LoginStatus вызывает метод SignOut, но это происходит после того, как модуль FormsAuthenticationModule проверит подлинность пользователя. Таким образом, явное перенаправление приводит к тому, что браузер повторно запрашивает страницу. К тому времени, когда браузер повторно запрашивает страницу, билет аутентификации форм уже удален, и, следовательно, входящий запрос является анонимным.

• Перенаправление – пользователь перенаправляется на URL, указанный в свойстве LogoutPageUrl объекта LoginStatus.
• RedirectToLoginPage – пользователь перенаправляется на страницу входа.

Давайте добавим элемент управления LoginStatus на главную страницу и настроим его на использование параметра Redirect для перенаправления пользователя на страницу, на которой отображается сообщение, подтверждающее, что он вышел из системы. Начните с создания страницы в корневом каталоге с именем Logout.aspx. Не забудьте связать эту страницу с главной страницей Site.master. Далее введите сообщение в разметке страницы, объясняющее пользователю, что он вышел из системы.

Затем вернитесь на главную страницу Site.master и добавьте элемент управления LoginStatus под LoginView в LoginContent ContentPlaceHolder. Установите для свойства LogoutAction элемента управления LoginStatus значение Redirect, а для свойства LogoutPageUrl — значение "~/Logout.aspx".

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        <br />
        <asp:LoginStatus ID="LoginStatus1" runat="server" LogoutAction="Redirect" LogoutPageUrl="~/Logout.aspx" />
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Поскольку LoginStatus находится за пределами элемента управления LoginView, он будет отображаться как для анонимных, так и для аутентифицированных пользователей, но это нормально, так как LoginStatus будет правильно отображать кнопку ссылки "Login" или "Logout". С добавлением элемента управления LoginStatus гиперссылка «Войти» в AnonymousTemplate становится лишней, поэтому удалите ее.

На рисунке 18 показано Default.aspx когда приходит Jisun. Обратите внимание, что в левом столбце отображается сообщение «С возвращением, Джисун» вместе со ссылкой для выхода из системы. Нажатие кнопки выхода из системы вызывает постбек, выводит Jisun из системы, а затем перенаправляет ее на Logout.aspx. Как показано на рисунке 19, к тому времени, когда Цзисон достигает Logout.aspx она уже вышла из системы и, следовательно, является анонимной. Следовательно, в левой колонке отображается текст «Добро пожаловать, незнакомец» и ссылка на страницу входа.

Рисунок 18: Default.aspx показывает "С возвращением, Jisun" вместе с кнопкой "Выйти" (Нажмите, чтобы просмотреть полноразмерное изображение)

Рисунок 19: Logout.aspx показывает "Добро пожаловать, незнакомец" вместе со ссылкой "Войти" (Нажмите, чтобы просмотреть полноразмерное изображение)

Замечание

Я рекомендую вам настроить страницу Logout.aspx так, чтобы скрыть LoginContent ContentPlaceHolder главной страницы (как мы сделали для Login.aspx в Шаге 4). Причина в том, что кнопка LinkButton "Login", отображаемая элементом управления LoginStatus (тот, что находится под "Hello, stranger"), отправляет пользователя на страницу входа, передавая текущий URL-адрес в параметре строки запроса ReturnUrl. Короче говоря, если пользователь, который вышел из системы, нажмет кнопку «Войти» в этом LoginStatus, а затем войдет в систему, он будет перенаправлен обратно на Logout.aspx, что может легко запутать пользователя.

Сводка

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

Класс FormsAuthentication в .NET Framework включает методы для создания, проверки и удаления билетов проверки подлинности форм. Свойство Request.IsAuthenticated и объект User обеспечивают дополнительную программную поддержку для определения того, прошел ли запрос проверку подлинности, и получения сведений об удостоверении пользователя. Существуют также веб-элементы управления LoginView, LoginStatus и LoginName, которые предоставляют разработчикам быстрый способ выполнения многих общих задач, связанных со входом в систему, без написания кода. Мы рассмотрим эти и другие веб-элементы управления, связанные со входом в систему, более подробно в будущих руководствах.

В этом руководстве представлен краткий обзор проверки подлинности с помощью форм. Мы не рассматривали различные варианты конфигурации, не рассматривали, как работают билеты проверки подлинности форм без файлов cookie, и не изучали, как ASP.NET защищает содержимое билета проверки подлинности форм.

Счастливое программирование!

Дальнейшее чтение

Дополнительные сведения о разделах, описанных в этом руководстве, см. в следующих ресурсах:

• Изменения между безопасностью IIS6 и IIS7
• Управление входом в систему ASP.NET
• Профессиональный ASP.NET 2.0 безопасность, членство и управление ролями (ISBN: 978-0-7645-9698-8)
• Элемент <authentication>
• Элемент <forms> для <authentication>

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

• Использование базовой проверки подлинности на основе форм в ASP.NET

Сведения о авторе

Скотт Митчелл, автор семи книг ASP/ASP.NET и основатель 4GuysFromRolla.com, работает с технологиями Microsoft Web с 1998 года. Скотт работает независимым консультантом, тренером и писателем. Его последняя книга — Sams Teach Yourself ASP.NET 2.0 за 24 часа. С ним можно связаться по адресу mitchell@4GuysFromRolla.com.

Особое спасибо...

Эта серия учебников была проверена многими полезными рецензентами. Ведущий рецензент для этого руководства был рассмотрен многими полезными рецензентами. Ведущие рецензенты этого руководства включают Alicja Maziarz, Джон Suru и Тереза Мерфи. Хотите просмотреть мои предстоящие статьи MSDN? Если да, напишите мне на mitchell@4GuysFromRolla.com.

НазадДалее