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

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

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

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

Дополнительные сведения по этой теме см. в этом видео: использование проверки подлинности Basic Forms в ASP.NET.

Введение

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

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

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

Основные сведения о рабочем процессе проверки подлинности на формах

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

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

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

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

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

Рабочий процесс проверки подлинности с помощью форм

Рис. 1. Рабочий процесс проверки подлинности с помощью форм

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

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

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

Note

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

Область проверки подлинности с помощью форм

FormsAuthenticationModule— Это управляемый код, который является частью среды выполнения ASP.NET. До версии 7 веб-сервера Microsoft службы IIS (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 и Урлаусоризатионмодуле в конвейер HTTP IIS, тем самым расширяя эту функциональность на все запросы.

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

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

Note

Демонстрационное веб-приложение, используемое в каждом учебнике, доступно для загрузки. Это загружаемое приложение было создано с помощью 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, _ папкой данных приложения и файлом Web.config.

Note

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

Создание нового файла System-Based веб-сайте

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

Добавление главной страницы

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

Добавление главной страницы с именем site. master на веб-сайт

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

Определите макет страницы для всего сайта на главной странице. Вы можете использовать представление конструирования и добавлять необходимые макеты или веб-элементы управления, или вручную добавить разметку в представлении источника. Макет главной страницы был структурирован так, чтобы имитировать макет, используемый при работе с данными в руководстве по 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), но у главной страницы может быть несколько элементов управления ContentPlaceHolder.

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

Эталонная страница при просмотре в режиме конструктора

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

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

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

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

Добавление новой страницы Default. aspx выбор главной страницы

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

Использование главной страницы Site. master

Рис. 6. Использование главной страницы Site. master

Note

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

Новая декларативная разметка страницы Default. aspx включает только @Page директиву, указывающую путь к файлу главной страницы и элемент управления содержимым для 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. Далее в этом руководстве мы вернемся к нему, чтобы добавить содержимое.

Note

Главная страница содержит раздел для меню или другой интерфейс навигации. В следующем учебном курсе мы создадим такой интерфейс.

Шаг 2. Включение проверки подлинности с помощью форм

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

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

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

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

Если проект еще не содержит 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>

Note

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

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

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

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

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

Страница входа имеет три обязанности:

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

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

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

Добавьте новую страницу ASP.NET с именем Login. aspx.

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

Стандартный интерфейс страницы входа состоит из двух текстовых полей: одно для имени пользователя, одно для пароля и кнопку для отправки формы. Веб-сайты часто содержат флажок "Запомнить меня", который, если отмечено, сохраняет итоговый билет проверки подлинности при перезапуске браузера.

Добавьте два текстовых поля в login. aspx и задайте ID для них свойства UserName и Password соответственно. Также задайте TextMode для свойства пароля значение Password. Затем добавьте элемент управления CheckBox, установив для его ID свойства значение rememberMe и его Text свойство в значение «запомнить меня». После этого добавьте кнопку с именем Логинбуттон, Text свойство которой имеет значение login. И, наконец, добавьте элемент управления Label и задайте ID для его свойства значение инвалидкредентиалсмессаже, а Text свойству — недопустимое имя пользователя или пароль. Повторите попытку. ", его ForeColor свойство — красный, а 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 Логинбуттон. В конструкторе просто дважды щелкните элемент управления "Кнопка", чтобы создать этот обработчик событий.

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

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

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

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

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

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;
}

Как видите, есть три действительных учетных записи: Скотт, Цзисунь и SAM — и все три имеют одинаковый пароль ("пароль"). Код просматривает массивы пользователей и паролей для поиска допустимого имени пользователя и пароля. Если имя пользователя и пароль действительны, необходимо выполнить вход пользователя и перенаправить их на соответствующую страницу. Если учетные данные недопустимы, отобразится метка Инвалидкредентиалсмессаже.

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

Login. aspx? ReturnUrl = Протектедпаже. aspx

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

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

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

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

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

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

FormsAuthentication. RedirectFromLoginPage (имя_пользователя. Text, RememberMe. Checked);

При создании билета проверки подлинности с помощью форм мы используем свойство Text текстового поля UserName для параметра имени пользователя билета проверки подлинности Forms и состояние Checked флажка rememberMe для параметра персисткукие .

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

При вводе недопустимых учетных данных отображается метка Инвалидкредентиалсмессаже

Рис. 10. метка Инвалидкредентиалсмессаже отображается при вводе недопустимых учетных данных (щелкните, чтобы просмотреть изображение с полным размером)

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

На шаге 5 рассматриваются методы входа пользователя из веб-сайта в журнал.

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

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

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

Note

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

Шаг 4. Обнаружение прошедших проверку подлинности посетителей и определение их удостоверения

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

Добавим существующую страницу Default. aspx, чтобы продемонстрировать эти приемы. В Default. aspx добавьте два элемента управления Panel: один с именем Аусентикатедмессажепанел и другой с именем Анонимаусмессажепанел. Добавьте элемент управления Label с именем Велкомебаккмессаже на первой панели. На второй панели добавьте элемент управления HyperLink, задайте для его свойства Text значение "вход" и свойство NavigateUrl в значение "~/Логин.аспкс". На этом этапе декларативная разметка для 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>

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

Свойство request. Authenticator возвращает логическое значение, указывающее, прошел ли запрос проверку подлинности. Введите следующий код в _ код обработчика событий загрузки страницы:

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. Пользователи, прошедшие проверку подлинности, показывают "Добро пожаловать!" Сообщение

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

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

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

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

String Куррентусерснаме = User.Identity.Name;

При использовании проверки подлинности с помощью форм для свойства Identity GenericPrincipal создается объект FormsIdentity . Класс FormsIdentity всегда возвращает строку Forms для своего свойства AuthenticationType и значение true для свойства, прошедшего проверку подлинности. Свойство Name возвращает имя пользователя, указанное при создании билета проверки подлинности с помощью форм. Помимо этих трех свойств, FormsIdentity включает доступ к базовому билету проверки подлинности через свойство Ticket. Свойство Ticket возвращает объект типа формсаусентикатионтиккет, который имеет такие свойства, как Expires, Иссуедате, Name и т. д.

Важно отметить, что параметр username , указанный в методах FormsAuthentication. жетаускукие (имя_пользователя, Персисткукие), FormsAuthentication.Сетаускукие (username, персисткукие) и FormsAuthentication. RedirectFromLoginPage (username, персисткукие), совпадает со значением, возвращенным User.Identity.Name. Более того, билет проверки подлинности, созданный этими методами, доступен путем приведения пользователя. Identity к объекту FormsIdentity и получения доступа к свойству Ticket:

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

Давайте предоставляющим более персонализированное сообщение в Default. aspx. Обновите _ обработчик событий загрузки страницы, чтобы свойству Text метки велкомебаккмессаже было присвоено строковое значение "Добро пожаловать, username!".

Велкомебаккмессаже. Text = "Добро пожаловать," + User.Identity.Name + "!";

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

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

Рис. 13. Приветственное сообщение содержит имя текущего пользователя, выполнившего вход

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

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

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

  • Анонимаустемплате — любая разметка, добавленная в этот шаблон, отображается только для анонимных посетителей.
  • Логжединтемплате — разметка этого шаблона отображается только для пользователей, прошедших проверку подлинности.

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

Note

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

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

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

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

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

Элемент управления 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, Стрэнджер" в Анонимаустемплате; Затем добавьте элемент управления HyperLink и задайте для его свойств Text и NavigateUrl значение "вход" и "~/Логин.аспкс" соответственно.

После настройки Анонимаустемплате переключитесь на Логжединтемплате и введите текст «Добро пожаловать». Затем перетащите элемент управления LoginName с панели инструментов в Логжединтемплате, поместив его сразу после текста «Добро пожаловать». Элемент управления 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 при посещении через браузер пользователем Цзисунь. Сообщение "Добро пожаловать, Цзисунь" повторяется дважды: один раз в разделе навигации главной страницы слева (через элемент управления LoginView, который мы только что добавили) и один раз в области содержимого Default. aspx (с помощью элементов управления Panel и программной логики).

Элемент управления LoginView отображает

Рис. 15. элемент управления LoginView отображает «Добро пожаловать, цзисунь».

Так как мы добавили объект LoginView на главную страницу, он может отображаться на каждой странице сайта. Однако могут существовать веб-страницы, на которых не нужно выводить это сообщение. Одной из таких страниц является страница входа в систему, так как ссылка на страницу входа кажется на месте. Так как мы поместили элемент управления LoginView в ContentPlaceHolder на главной странице, мы можем переопределить эту разметку по умолчанию на странице содержимого. Откройте Login. aspx и перейдите в конструктор. Так как мы не создали явно элемент управления содержимым в файле Login. aspx для Логинконтент ContentPlaceHolder на главной странице, на странице входа будет показана разметка по умолчанию для этой страницы ContentPlaceHolder на главной странице. Это можно увидеть с помощью конструктора — Логинконтент ContentPlaceHolder показывает разметку по умолчанию (элемент управления LoginView).

На странице входа отображается содержимое по умолчанию для Логинконтент ContentPlaceHolder главной страницы.

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

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

Note

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

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

Страница входа скрывает разметку Логинконтент ContentPlaceHolder по умолчанию

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

Шаг 5. выход из сеанса

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

Предложение выхода из системы — это общая функция, которая ASP.NET включает элемент управления, специально предназначенный для входа пользователя в систему. Элемент управления LoginStatus отображает LinkButton "Login" или "Logout" в зависимости от состояния проверки подлинности пользователя. Отображается «login» LinkButton для анонимных пользователей, тогда как элемент LinkButton «Logout» отображается для пользователей, прошедших проверку подлинности. Текст для элемента LinkButton "Login" и "Logout" можно настроить с помощью свойств LoginStatus Логинтекст и Логауттекст.

При нажатии LinkButton "Login" вызывается обратная передача, из которой перенаправление выдается странице входа. Если щелкнуть LinkButton "Logout", элемент управления LoginStatus вызовет метод FormsAuthentication., а затем перенаправляет пользователя на страницу. Страница, с которой выполнен выход из системы, зависит от свойства Логаутактион, которое может быть назначено одному из следующих трех значений:

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

Возможно, вам интересно, почему выполняется перенаправление. Если пользователь хочет остаться на той же странице, зачем нужно явно перенаправление? Причина заключается в том, что при нажатии на элемент LinkButton "logoff" пользователь по-прежнему имеет билет проверки подлинности форм в своей коллекции файлов cookie. Следовательно, запрос на обратную передачу является запросом, прошедшим проверку подлинности. Элемент управления LoginStatus вызывает метод Sign, но это происходит после того, как FormsAuthenticationModule проходил проверку подлинности пользователя. Таким образом, явное перенаправление заставляет браузер повторно запрашивать страницу. К моменту, когда браузер повторно запрашивает страницу, билет проверки подлинности на основе форм был удален, поэтому входящий запрос анонимен.

  • Redirect — пользователь перенаправляется по URL-адресу, указанному в свойстве Логаутпажеурл LoginStatus.
  • Редиректтологинпаже — пользователь перенаправляется на страницу входа.

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

Затем вернитесь на главную страницу site. master и добавьте элемент управления LoginStatus под узлом LoginView в Логинконтент ContentPlaceHolder. Задайте для свойства Логаутактион элемента управления LoginStatus значение Redirect и его свойство Логаутпажеурл значение "~/логаут.аспкс".

<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 будет правильно отображать элемент управления LinkButton "Login" или "Logout". С добавлением элемента управления LoginStatus гиперссылка для входа в Анонимаустемплате является избыточной, поэтому удалите ее.

На рис. 18 показан Default. aspx при посещении Цзисунь. Обратите внимание, что в левом столбце отображается сообщение "Добро пожаловать, Цзисунь" и ссылка для выхода из нее. Если щелкнуть элемент LinkButton, выполнит обратную передачу, подписывает Цзисунь из системы, а затем перенаправит его в Logout. aspx. Как показано на рис. 19, время, когда Цзисунь доходит до выхода. aspx, он уже выполнил выход и поэтому является анонимным. Следовательно, в левом столбце отображается текст "Добро пожаловать, Стрэнджер" и ссылка на страницу входа.

Default. aspx показывает

Рис. 18. Default. aspx показывает "Добро пожаловать, Цзисунь" вместе с LinkButton "Logout" (щелкните, чтобы просмотреть изображение с полным размером)

В файле Logout. aspx отображаются

Рис. 19. logout. aspx отображает "Welcome, Стрэнджер" вместе с "Login" LinkButton (щелкните, чтобы просмотреть изображение с полным размером)

Note

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

Сводка

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

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

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

Поздравляем с программированием!

Дополнительные материалы

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

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

Об авторе

Скотт Митчелл, автор семи книг по ASP/ASP. NET и основатель 4GuysFromRolla.com, работал с веб-технологиями Майкрософт с 1998. Скотт работает как независимый консультант, преподаватель и модуль записи. Его последняя книга — Sams обучать себя ASP.NET 2,0 за 24 часа. Он доступен по адресу mitchell@4GuysFromRolla.com . или через его блог, который можно найти по адресу http://ScottOnWriting.NET .

Особая благодарность...

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