|
» ASP
для новичков
» Главная
страница
»
ASP
для новичков
Аутентификация и
авторизация пользователей
Любой более или менее
разветвленный сайт должен уметь сортировать своих посетителей по уровню их прав.
Так, обычному посетителю будет открываться только информационная часть сайта, но
допускать его до административных интерфейсов сайта не рекомендуется. Сайты,
практикующие подписку на предоставляемые ресурсы,
дают всем пользователям только часть своего контента, а доступ к полной своей
версии предлагают своим подписчикам. Следовательно, Web-разработчик должен уметь
использовать механизмы обеспечения безопасности, применительно к своим сайтам.
При разработке сайтов для
обеспечения безопасности часто используется связка из двух процедур —
аутентификации и авторизации. Аутентификация позволяет приложению узнать, какой
именно пользователь посетил сайт. Обычно это прием некоего пароля или иного
цифрового идентификатора, такого как номер кредитной карты или цифровое
удостоверение, подтвержденное третьей стороной. Авторизация позволяет
определять, какие именно Web-страницы или их категории будут доступны данному
конкретному посетителю. Именно процедура авторизации сообщит сайту, что
администратору будут предоставляться все Web-страницы, легальному подписчику все
страницы с контентом, обычному гостю — страницы с общедоступной информацией, а
хакеру, который ввел украденный пароль, — всего одна Web-страница с официальным
предупреждением. Естественно, авторизация может проводиться только после
завершения аутентификации.
Нам предстоит в этом разделе
рассмотреть обе эти процедуры, и начнем мы, конечно, именно с аутентификации.
В ASP.NET предусмотрено три
варианта аутентификации. Разработчик может воспользоваться аутентификацией,
основанной на обычной процедуре распознавания пользователя операционной системой
Windows, аутентификацией на основе cookie-файлов, и аутентификацией, основанной
на технологии Microsoft Passport. И, конечно, разработчик может вообще не
использовать проверку подлинности, но это уже удел самых простых сайтов.
Для начала рассмотрим механизм
использования аутентификации, основанной на механизме опознания пользователя
операционной системой Windows. В этом случае сервер будет выводить диалоговое
окно, в котором пользователь введет свое имя и пароль. Введенное имя и пароль
должны совпадать с учетной записью используемого домена Windows, т. е. все
пользователи сайта должны быть прописаны в операционной системе. Естественно,
подобный вариант аутентификации будет плохо уживаться с требованиями обычных
сайтов, так как использовать учетные записи операционной системы для всех
посетителей сайта — явно не самый лучший вариант. Но вот при работе
корпоративного сайта в интрасети это практически лучший выбор, так как все
пользователи гарантированно имеют свои учетные записи в домене, и разработчик
имеет возможность без лишних хлопот аутенти-фицировать и авторизовать
пользователя.
Второй вариант
аутентификации, как мы уже говорили, основан на применении cookies. Когда
пользователь первый раз появляется на сайте, Web-приложение запрашивает его
регистрационное имя и пароль. После прохождения первичной идентификации
приложение формирует cookie-файл, который записывается в локальной
системе удаленного пользователя. Затем, когда пользователь будет запрашивать
какую-либо Web-страницу, этот cookie-файл будет автоматически передаваться
браузером на сервер, и на основе этого cookie пользователь будет автоматически
распознаваться. Таким образом, мы избавляем пользователя от необходимости
вводить пароль для доступа к каждой защищенной Web-странице. После завершения
сеанса работы приложение может объявить созданный cookie-файл устаревшим, и дри
следующем появлении этого пользователя на сайте снова запросить его
регистрационное имя или пароль, либо приложение может пользоваться единожды
созданным cookie постоянно, опознавая пользователя самостоятельно при каждом его
последующем заходе на сайт.
Третий вариант аутентификации
пользователей опирается на использование технологии Microsoft Passport. Эта
технология позволяет хранить все данные каждого конкретного пользователя в одном
месте. На самом деле, для аутентификации опять будет применяться cookie-файл или
запрос пароля, но всю эту работу будет выполнять сервер Microsoft Passport.
Запись о пользователе в базе данных этого сервера будет являться пропуском ко
всем сайтам, на которые он заходит (если эти сайты в свою очередь могут
использовать технологию Microsoft Passport). Идея, в принципе, хороша. Каждый,
кто находится в Сети достаточно долгое время, знает, сколько разных паролей и
регистрационных имен ему приходилось вводить на самых различных сайтах. Поэтому,
когда пользователь заходит в один из своих любимых онлайновых магазинов, ему
приходится или вспоминать свое регистрационное имя и пароль, либо пользоваться
службой напоминания пароля, когда на его адрес электронной почты сайт высылает
идентификационные данные. Вот только надо еще вспомнить, какой именно адрес
электронной почты вводился на этом сайте.
Microsoft Passport снимает подобную
проблему, так как он хранит данные о пользователе, и сайту необходимо лишь
получить эти данные с сервера службы Passport. Помимо идентификационных данных
сервер Microsoft Passport может хранить персональные сведения пользователей,
такие как адрес электронной почты и номер кредитной карты. Таким образом,
пользователю, который обзавелся подобным цифровым паспортом, уже не придется на
сайтах, поддерживающих эту технологию, вообще вводить какие-либо персональные
данные. Сайт будет их узнавать от службы Microsoft Passport. С этой точки
зрения, использование подобной паспортной службы кажется очень хорошим решением.
Однако не все так радужно.
Прежде всего, следует
задуматься о том, что все персональные данные пользователя, в том числе и
критичные, такие, как номер кредитной карты, будут храниться на отдельном
сервере в Сети. Что будет, если этот сервер "упадет", как уже бывало один раз с
сервером Microsoft? Или, если его все-таки взломают, несмотря на обещанную
"непробиваемую защиту"? Все мы прекрасно знаем, что абсолютной защиты не бывает,
и вероятность утери или разглашения конфиденциальных
данных отлична от нуля. Сама концепция хранения такого массива критичных данных
на централизованном сервере (даже если серверов будет несколько, они все равно
будут функционировать как один сервер) вызывает некоторую опаску. И неужели
можно предположить, что в случае утери или компрометации конфиденциальных
данных, корпорация Microsoft возместит ущерб? Честно говоря, я с трудом верю в
подобный исход.
Есть и еще один подводный камень в
использовании этого сервиса. Дело в том, что пользователь должен видеть реальные
преимущества от применения цифровых паспортов от Microsoft, т. е. количество
сайтов, использующих эти паспорта, должно быть достаточно велико. Однако
распространение данной технологии среди разработчиков сдерживает тот факт, что
Microsoft требует лицензировать применение Passport и просит оплатить свои
услуги. Естественно, подобные действия весьма типичны для корпорации Microsoft,
однако они будут достаточно серьезно сдерживать внедрение Microsoft Passport в
массы.
Впрочем, делать прогнозы сейчас —
дело неблагодарное. Microsoft активно продвигает с помощью маркетинговых
мероприятий идею Passport. При этом основной упор корпорация делает на развитие
сервисов, которые опознают пользователей именно по их цифровым паспортам. Данная
инициатива носит наименование Hailstorm. О создании сервисов речь пойдет в
последней главе этой книги, поэтому пока мы не будем останавливаться на этой
теме.
Исходя из вышеперечисленного,
становится ясно, что на настоящий момент разработчик может использовать только
два варианта аутентификации пользователей. Для обычных сайтов стоит применять
аутентификацию на основе cookies, а для Web-приложений, действующих в среде
intranet, следует использовать стандартную аутентификацию Windows.
Следует упомянуть, что в
силу своей достаточно большой функциональности ASP.NET позволяет разработчику
создавать свои собственные механизмы аутентификации, но следует весьма аккуратно
разрабатывать архитектуру подобных процедур. Дело в том, что обычная пересылка
пароля и регистрационного имени может быть перехвачена обычным анализатором
трафика TCP. Поэтому, если в базе данных вашего сайта хранятся достаточно
критичные для пользователей данные, не стоит уповать только на ввод
регистрационного имени и пароля. Более того, даже использование cookie-файлов не
всегда решает эту проблему. Если пользователь раз за разом передает один и тот
же пароль, пусть даже и зашифрованный, или при пересылке запросов серверу
отсылается один и тот же cookie-файл, то злоумышленник, использующий перехватчик
сетевых пакетов, сможет вычленить эти данные из общего трафика, а затем
воспользоваться ими. Поэтому стоит каким-либо образом менять пароли и
cookie-файлы спустя некоторое время их использования, либо вообще после каждого
сеанса работы пользователя. Также при пересылке конфиденциальных данных
следует использовать протокол SSL (Secure Socket Layer), который шифрует
передаваемые данные. Это, конечно, несколько замедляет работу, но все разумные
способы, затрудняющие жизнь злоумышленникам, должны быть использованы.
Итак, мы узнали, какие именно
механизмы аутентификации пользователей предлагает нам ASP.NET. Теперь предстоит
рассмотреть примеры применения аутентификации на основе cookie-файлов и на
основе стандартных механизмов опознания пользователя Windows. Прежде всего,
следует отметить, что процессы аутентификации и авторизации пользователей
включаются в состав Web-приложения при помощи файла Config.Web. Нетрудно
догадаться, что этот файл хранит информацию о конфигурации приложения. Несколько
более детально процедуру конфигурирования приложений мы будем рассматривать в
одном из следующих разделов этой главы, а пока лишь вкратце рассмотрим структуру
этого файла.
Файл Config.Web является
стандартным XML-файлом. Тело этого файла разбито по умолчанию на восемь
разделов, которые отвечают за те или иные настройки приложения. Нас сейчас
интересует секция, объявляемая тегом <authentication>. Нетрудно
догадаться, что именно эта секция устанавливает параметры аутентификации,
используемой в разрабатываемом Web-приложении.
У тега
<authentication> есть обязательный атрибут mode, при помощи которого
разработчик устанавливает используемый Web-приложением режим аутентификации.
Данный атрибут может принимать одно из следующих четырех значений:
- None. Значение указывает, что
Web-приложение не использует какой-либо аутентификации.
- windows. Значение свидетельствует, что Web-приложение будет использовать
аутентификацию, основанную на стандартном механизме распознавания пользователя
операционной системы Windows.
- Forms. Значение указывает, что Web-приложение будет использовать
аутентификацию на основе cookie-файлов.
- Passport. Данное значение свидетельствует, что в Web-приложении будет
использоваться аутентификация, основанная на технологии Microsoft Passport. Для
того чтобы можно было использовать этот вариант идентификации пользователя,
следует установить на сервере соответствующий Passport SDK.
В нашем случае, естественно,
мы используем значение Forms. Общий вид конфигурационного файла Config.Web для
создаваемого нами приложения приведен в листинге 3.46.
Листи нг 3.46
<?xml version="1.0"
encoding="utf-8" ?> <configuration> <system.Web>
<compilation
defaultLanguage="vb" debug="true" />
<customErrors mode="RemoteOnly"
/>
<authentication mode="Forms">
<forms name="demoauth"
loginUrl="login.aspx" protection="All timeout="30" path="/">
</forms>
</authentication>
<authorization>
<allow users="*'
<!— <allow
<deny
/> <!— Allow all users —>
users="[comma separated list of users]"
roles="[comma separated list of
roles]"/>
users="[comma separated list of
users]" roles="[comma separated list of roles]"/>
</authorization>
<trace enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime" Iocal0nly="true" />
<sessionState mode="InProc"
stateConnectionString="tcpip= 127.0.0.1:42424"
sqlConnectionString="data
source=127.0.0.1;
user id=sa;password="
cookieless="false" timeout="20" />
<httpHandlers>
<add verb="*" path="*.vb" type=
"System.Web.HttpNotFoundHandler,System.Web" />
Odd verb="*" path="*.cs" type=
"System.Web.HttpNotFoundHandler,System.Web" />
Odd verb="*" path="*.vbproj" type=
"System.Web.HttpNotFoundHandler,System.Web" />
Odd verb="*" path="*.csproj" type=
' "System.Web.HttpNotFoundHandler,System.Web" />
Odd verb="*" path="*.Webinfo" type=
"System.Web.HttpNotFoundHandler,System.Web" />
</httpHandlers>
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
</system.Web>
</configuration>
Нас, естественно, будет
интересовать именно секция <authentication>. | Легко заметить, что кроме
указания соответствующего режима аутентификации пользователей при помощи
атрибута mode, мы разместили в ней дополнительный тег <forms> с различными
атрибутами. Этот тег при помощи атрибутов задает конкретные свойства
используемой процедуры аутентификации. Рассмотрим эти атрибуты.
- loginuri. Значением данного атрибута является URL страницы, на которую
отсылается пользователь, не прошедший аутентификацию. В нашем случае мы
используем страницу с именем "login.aspx".
- name. Этот атрибут задает наименование cookie, в котором и будут храниться
идентификационные данные удаленного пользователя.
- timeout. Свойство задает временной период, в течение которого cookie-файл
будет считаться действительным, если даже пользователь не отвечает на запросы.
Использование подобного периода тайм-аута позволяет уменьшить риск возникновения
ситуации, когда пользователь ввел свое имя и пароль, а затем прервал работу.
Если после этого злоумышленник начнет работу с сайтом с локальной машины
пользователя, то сайт получит правильный cookie и будет считать злоумышленника
легальным пользователем. Если же разработчик явно установит продолжительность
периода тайм-аута, то по истечении этого времени с последнего запроса,
пользователь вновь будет считаться не прошедшим аутентификацию, и сайт отправит
его на страницу ввода имени и пароля. Следует особо отметить, что период
тайм-аута начинает отсчитываться не с момента первого ввода регистрационного
имени и пароля, а каждый раз начинается заново, когда браузер пользователя
отправляет запрос на сервер. Значением данного атрибута является число,
указывающее длительность периода тайм-аута в минутах. По умолчанию используется
значение, равное тридцати.
- path. В этом параметре
указывается путь к виртуальным каталогам, для которых данный cookie-файл будет
действительным. При помощи этого параметра мы можем создавать несколько
cookie-файлов, в каждом из которых будет храниться уникальная информация. Это
позволит создать механизм многоступенчатой аутентификации, когда для доступа ко
всем более закрытым отделам сайта, пользователь будет вынужден вводить свои
дополнительные пароли. Но в последнее время подобной системе ступенчатого ввода
паролей все чаще присваивают эпитет "параноидальная". Разработчик должен очень
тщательно отнестись к проблеме поиска баланса между защищенностью Web-приложения
и удобством работы пользователя. По умолчанию для данного атрибута используется
значение "/", которое указывает, что создаваемый cookie-файл будет действителен
для всех виртуальных каталогов и Web-страниц, входящих в состав сайта.
- protection. Параметр устанавливает правила защиты создаваемого cookie-файла
от подделок. Параметр может иметь одно из следующих четырех значений:
- None. Значение указывает, что информация, записываемая в cookie-файл
пользователя, никаким образом не защищается от взлома. Естественно, это
несколько ускоряет работу приложений, но может использоваться только в тех
случаях, когда неверная идентификация пользователя не повлечет за собой
каких-либо убытков;
- Encription. При использовании этого значения содержимое cookie-файла
шифруется с помощью алгоритмов DES или "тройной DES" в зависимости от настроек
операционной системы (как известно. в США существуют ограничения на экспорт
программ с "сильной криптографией", поэтому официально за рубеж поставляется
версия Windows с ослабленными криптографическими возможностями). Однако
использование этого режима не позволяет полностью быть уверенным, что содержимое
cookie-файла не изменили, так как он остается подверженным традиционным
криптоатакам;
- validation. Значение указывает, что cookie-файл не будет шифроваться, однако
он будет проверяться на подлинность. Ключ подлинности, вырабатываемый
Web-приложением, будет добавлен к содержимому самого cookie-файла. К
получившимся данным будет добавлен МАС-адрес удаленного клиента;
- аll. Значение используется по умолчанию. Оно указывает, что для поддержки
безопасности идентификационных данных будет использоваться одновременно и
шифрование, и проверка подлинности.
Теперь, после того, как мы узнали,
каким образом настраивать приложения для поддержки аутентификации, можно перейти
к примеру приложения. Для демонстрации концепции аутентификации на основе
cookie-файлов, нам потребуется помимо конфигурационного файла еще две страницы.
На стартовой странице мы разместим обычное приветствие, в котором будет
упоминаться имя пользователя, а вторая страница будет содержать форму для ввода
имени и пароля. По умолчанию будет загружаться стартовая страница, но если
пользователь еще не проходил аутентификацию, он будет автоматически отсылаться
на страницу ввода имени и пароля без участия самого Web-приложения, т. е.
разработчику для этого не придется прикладывать каких-либо дополнительных
усилий.
На первой странице мы разместим
один компонент Label, текстовое содержимое которого будет формироваться
автоматически при загрузке страницы. Также на первой странице мы разместим один
независимый переключатель, реализуемый при помощи компонента checkBox. Если
пользователь установит флажок в этом переключателе, то его учетная запись будет
удалена, и в следующий раз ему придется снова проходить аутентификацию.
Естественно, свойство AutoPostBack для этого компонента необходимо будет
установить в значение True. Также установим для стартовой страницы имя
default.aspx, чтобы к ней можно было обращаться по умолчанию.
HTML-код начальной Web-страницы в
режиме ее разработки приведен в листинге 3.47.
Листинг 3.47
<%@ Page Language="vb"
AutoEventWireup="false" Codebehind="default.aspx.vb"
Inherits="cookieauth.WebForml"%>
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<titlex/title>
<meta name="GENERATOR"
content="Microsoft Visual Studio.NET 7.0">
<meta name="CODE_LANGUAGE"
content="Visual Basic 7.0">
<meta
name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema"
content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body
MS_POSITIONING="GridLayout">
<form id="Forml" method="post"
runat="server">
<asp:Label id="Labell"
style="Z-INDEX: 101; LEFT: 28px;
POSITION: absolute; TOP: ЗОрх"
runat="server" Width="158px" Height="19px"> Здравствуйте,</asp:Label>
<asp:CheckBox id="CheckBoxl"
style="Z-INDEX: 102; LEFT: 38px;
POSITION: absolute;
TOP: 93px" runat="server"
Text="Удaлить мою учетную запись"
AutoPostBack="True"x/asp:CheckBox>
</form>
</body>
</HTML>
Текстовую надпись на стартовой
странице мы будем формировать при загрузке Web-страницы, следовательно, снова
придется перехватывать событие Page_Load. При этом мы будем использовать имя
пользователя. Извлекать его придется из соответствующего объекта с именем user.
Этот объект имеет одно свойство identity, определяемое типом iidentity. Объекты
подобного типа имеют всего три свойства:
- AuthentificationType. Свойство
типа string. В нем указывается тип аутентификации, применяемой приложением;
- isAuthentificated. Логическое свойство типа Boolean, которое показывает,
прошел ли уже данный пользователь процедуру аутентификации, или еще нет;
- Name. Свойство типа string, в котором хранится логин пользователя.
Следовательно, для того чтобы
получить регистрационное имя пользователя, надо использовать конструкцию user,
identity.Name. Именно это и показано в листинге 3.48, в котором приведен код
класса, реализующего стартовую Web-страницу.
Листинг 3.48
Public Class WebForml
Inherits System.Web.UI.Page
Protected WithEvents CheckBoxl As
System.Web.Ul.WebControls.Checkbox
Protected WithEvents Labell As
System.Web.UI.WebControls.Label
#Region " Web Form Designer
Generated Code "
'This call is required by the Web
Form Designer.
<System.Diagnostics.DebuggerStepThrough()>
Private Sub InitializeComponent()
End Sub
Private Sub Page_Init(ByVal sender
As System.Object, ByVal
e As System.EventArgs) Handles
MyBase.Init
'CODEGEN: This method call is
required by the Web Form Designer
'Do not modify it using the code
editor. InitializeComponent()
End Sub
#End Region
Private Sub Page_Load(ByVal sender
As System.Object, ByVal
e As System.EventArgs) Handles
MyBase.Load
'Put user code to initialize the
page here Labell.Text = "Здравствуйте, " + User.Identity.Name
End Sub
Private Sub
CheckBoxl_CheckedChanged(ByVal sender
As System.Object, ByVal
e As System.EventArgs) Handles
CheckBoxl.CheckedChanged
If CheckBoxl.Checked Then
Web.Security.FormsAuthentication.SignOut()
Response.Redirect("login.aspx")
End If
End Sub
End Class
Процедуру, выполняемую при загрузке
Web-страницы, мы обсуждали перед листингом. Но в нем находится еще одна
процедура, о которой мы еще не говорили. Это обработчик события
CheckBoxl.CheckedChanged. Это событие будет инициироваться, когда пользователь
изменит состояние независимого переключателя checkboxl, расположенного на
Web-странице. В том случае, если пользователь отметил флажок в этом
переключателе, следует исключить его из списка аутентифицированных
пользователей, и вновь отправить на страницу с формой для ввода логина и пароля.
Для того чтобы признать
аутентификацию пользователя недействительной, следует выполнить метод signOut
объекта FormsAuthentication. Нужно отметить, что объект FormsAuthentication
принадлежит пространству имен System.Web.Security, которое по умолчанию не
включается в разрабатываемое приложение. Поэтому следует или указывать полное
имя объекта, как мы и сделали в примере, либо импортировать это пространство
имен для приложения. Импортирование пространства имен System.Web.Security будет
производиться при помощи следующей директивы: <%@ Import
Namespace="System.Web.Security" %>
После того, как аутентификация
пользователя будет признана недействительной, его необходимо будет переправить
на страницу для ввода имени и пароля. Для этого мы используем метод Redirect
объекта Response.
Теперь перейдем к разработке
Web-страницы, предназначенной для ввода пользователем своего имени и пароля. Нам
потребуется разместить на ней два поля текстового ввода вместе с текстовыми
пояснениями к ним и одну кнопку, подтверждающую ввод данных. HTML-код
Web-страницы в режиме ее разработки приведен в листинге 3.49.
Листинг 3.49
<%@ Page Language="vb"
AutoEventWireup="false" Codebehind="Login.aspx.vb"
Inherits="cookieauth.Login"%>
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<titlex/title>
<meta name="GENERATOR"
content="Microsoft Visual Studio.NET 7.0">
<meta name="CODE_LANGUAGE"
content="Visual Basic 7.0">
<meta
name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema"
content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body
MS_POSITIONING="GridLayout">
<form id="Forml" method="post"
runat="server">
<asp:Label id="Labell"
style="Z-INDEX: 101; LEFT: Збрх;
POSITION: absolute; TOP: 27px"
runat="server" Width="219px" Height="19px"> Введите свой логин и
пароль</азр:ЬаЬе!>
<asp:Label id="Labe!2"
style="Z-INDEX: 102; LEFT: 41px;
POSITION: absolute;
TOP: 65px"
runat="server"xnornH</asp:Label>
<asp:Label id="Labe!3"
style="Z-INDEX: 103; LEFT: 40px;
POSITION: absolute; TOP: lOlpx"
runat="server">naponb</asp:Label>
<asp:TextBox id="Log"
style="Z-INDEX: 104; LEFT: 103px;
POSITION: absolute;
TOP: 60px"
runat="server"x/asp:TextBox>
<asp:TextBox id="Pass"
style="Z-INDEX: 105; LEFT: 104px;
POSITION: absolute;
TOP: 95px"
runat="server"x/asp:TextBox>
<asp:Button id="Buttonl"
style="Z-INDEX: 106; LEFT: 47px;
POSITION: absolute;
TOP: 143px" runat="server"
Height="24px" Width="169px" Text="noflTBepjiHTb "></asp: Button>
<asp:Label id="Label4"
style="Z-INDEX: 107; LEFT: 47px;
POSITION: absolute;
TOP: 190px" runat="server"
ForeColor="Red" Visi-Ые="Ра1зе">Неверный логин или naponb</asp:Label>
</form>
</body>
</HTML>
Анализируя приведенный листинг,
легко заметить, что на Web-странице помимо основных органов управления мы
поместили еще один текстовый компонент Label, который изначально сделан
невидимым. Он предназначен для отображения текстовой информации о вводе
неправильного пароля или логина. В том случае, если логин и пароль не будут
опознаны, эта надпись будет сделана видимой. Естественно, во избежание
сохранения ее видимого состояния при последующих загрузках можно еще при каждой
загрузке страницы принудительно делать ее невидимой. Все эти действия
реализованы в классе, соответствующем этой Web-странице. Код искомого класса
приведен в листинге 3.50.
Листинг 3.50
Public Class Login
Inherits System.Web.UI.Page
Protected WithEvents Label2
As System.-Web.UI .WebControls.
Label
Protected WithEvents Label3
As System.Web.UI.WebControls.Label
Protected WithEvents Buttonl
As System.Web.Ul.WebControls.Button
Protected WithEvents Log
As
System.Web.UI.WebControls.TextBox Protected WithEvents Pass
As
System.Web.Ul.WebControls.TextBox Protected WithEvents Label4
As System.Web.Ul.WebControls.Label
Protected WithEvents Labell
As System.Web.UI.WebControls.Label
IfRegion " Web Form Designer
Generated Code "
'This call is required by the Web
Form Designer.
<System.Diagnostics.DebuggerStepThrough()>
Private Sub InitializeComponent()
End Sub
Private Sub Page_Init(ByVal sender
As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init
'CODEGEN: This method call is
required by the Web Form Designer
'Do not modify it using the code
editor. InitializeComponent()
End Sub
fllEnd Region
Private Sub Page_Load(ByVal sender
As System.Object, ByVal
e As System.EventArgs)
Handles MyBase.Load
'Put user code to initialize the
page here Label4.Visible = False
End Sub
Private Sub Buttonl_Click(ByVal
sender As System.Object, ByVal
e As System.EventArgs) Handles
Buttonl.Click
If (Log.Text = "Igor") And
(Pass.Text = "mypassword") Then
Web.Security.FormsAuthentication.RedirectFromLoginPage(Log.Text, True)
Else
Label4.Visible = True
End If
End Sub
Epd Class
Рассмотрим действия, выполняемые
приложением после того, как пользователь заполнит поля для ввода
регистрационного имени и пароля и нажмет подтверждающую кнопку. Прежде всего,
необходимо узнать, какие именно данные ввел пользователь и сравнить их с
допустимым именем и паролем. В нашем случае, доступ к основной странице
предоставляется только пользователю с именем Igor, которому соответствует пароль
mypassword. В том случае, если введенные пользователем данные удовлетворяют
этому условию, пользователь переправляется на страницу, которая и затребовала
проведение аутентификации. Для этого используется метод
RedirectFromLoginPage объекта
FormsAuthentication. Этому методу передаются два параметра. В качестве первого
параметра передается имя пользователя. Второй параметр имеет логический тип
Boolean. В том случае, если второй параметр имеет значение True, созданный
идентификационный cookie-файл сохраняется на машине пользователя, и в следующий
визит ему уже не придется снова проходить процедуру аутентификации.
В том случае, если имя и пароль,
введенные пользователем, не соответствуют установленному условию, надпись о
запрете доступа визуализируется, и пользователь остается на текущей странице. На
рис. 3.29 и 3.30 показан внешний вид разработанных Web-страниц при отображении
их браузером Internet Explorer.
Естественно, метод проверки
правильности идентификационных данных, показанный в примере, практически никогда
не будет использоваться, так как обычно учетных записей пользователей достаточно
много и все их сохранять в коде страницы просто невозможно. Обычно эти данные
хранятся либо в базе данных, либо в отдельном файле, и процедура аутентификации
пользователя будет занимать несколько больше времени. Впрочем, есть еще один вариант
хранения учетных записей пользователей. Их идентификационные данные могут
храниться в конфигурационном файле Config.Web. Для этого необходимо в модуль
авторизации добавить раздел, объявляемый тегом <credentials>. В общем виде
этот раздел при хранении в нем учетных записей пользователей будет выглядеть
следующим образом:
authentication mode="Forms">
<forms name="demoauth"
loginUrl="login.aspx" protection="All" ^timeout="30" path="/">
<credentials
passwordFormat="Clear" >
<user name="Userl"
password="passl"/>
<user name="User2"
password="pass2"/>
</credentials>
</forms>
</authentication>
Видно, что у тега
<credentials> существует атрибут passwordFormat. С его помощью указывается
формат хранения паролей в конфигурационном файле. Этот атрибут должен принимать
одно из следующих трех значений:
- clear. Значение указывает, что
пароль хранится в виде обычного текста;
- shai. Значение указывает, что пароли подвергаются хэшированию по алгоритму
SHA1;
- MD5. Значение указывает, что пароли подвергаются хэшированию по алгоритму
MD5.
Естественно, Web-приложению
необходимо получать данные о пользователях из конфигурационного файла. Для этого
следует использовать метод
FormsAuthentication.Authenticate. В
качестве параметров методу передаются имя и пароль пользователя как значения
типа string. Метод возвращает логическое значение типа Boolean. В том случае,
если переданные методу идентификационные данные есть в конфигурационном файле,
метод возвращает значение True.
Теперь, когда мы разобрались с
аутентификацией пользователей, основанной на применении cookie-файлов, можно
перейти к рассмотрению аутентификации, основанной на стандартном механизме
распознавания пользователей операционной системой Windows.
Как мы уже знаем, для включения
этого режима аутентификации, секция <authentication> в конфигурационном
файле должна выглядеть следующим образом:
Authentication mode="Windows" />
Естественно, при использовании
такого режима аутентификации Web-разработчику нет нужды создавать свою страницу
для ввода имени и пароля, так как пользователь уже ввел свои данные, когда
загружал операционную систему. Остается лишь получить эти данные и
воспользоваться ими.
Разработчику не нужно знать пароля
пользователя, достаточно знать лишь его регистрационное имя. А оно располагается
в свойстве объекта user. Точнее, в свойстве user.identity.Name, которое мы уже
рассматривали. В системах Windows пользователи имеют не только имена. Они еще и
могут относиться к разным группам. Каждая группа имеет свои собственные права.
Для того чтобы узнать, принадлежит ли пользователь к какой-либо группе, следует
воспользоваться методом user.isinRoie. В качестве параметра этому методу
передается наименование какой-либо группы пользователей в Windows, а метод
возвращает логическое значение типа Boolean. В том случае, если пользователь
действительно входит в указанную группу, возвращается .значение True.
Этот метод аутентификации хорош
тем, что разработчик не должен думать, где и как хранить учетные записи
пользователей. Но это преимущество одновременно является и недостатком этого
метода аутентификации, так как ее могут проходить только те пользователи,
которые зарегистрированы в том же домене, что и IIS. Все это естественным
образом ограничивает применение этого метода пределами интрасетей.
Однако следует отметить, что,
основываясь на этом методе аутентификации. разработчик получает отличные
возможности для авторизации пользователей. Процесс авторизации позволяет
определить, разрешено ли пользователю получить какую-либо Web-страницу или нет.
Как мы уже видели, в
конфигурационном файле config.Web есть секция <authorization>. Именно она
и позволяет определять, кому из пользователей разрешено просматривать
Web-страницы, которые находятся в зоне действия конфигурационного файла. Вот
как выглядит типичный пример определения параметров авторизации:
<authorizatdon>
<allow users="userl" />
<allow roles="Administrators"
/>
<deny users="*" />
</authorization>
Легко заметить, что в секции
<authorization> находятся теги <aiiow> и <deny>. Именно они
определяют, кому будет разрешен доступ к страницам, а кому — запрещен. Теги
<aiiow>, естественно, описывают разрешения а доступ, а теги <deny> —
запрещения. Рассмотрим наш пример несколько ?;более внимательно.
Если в теге <aiiow> мы
используем атрибут users, то этот тег позволяет определять конкретного
пользователя, которому разрешен доступ к страницам. В качестве значения атрибута
следует указать имя искомого пользователя. Если использовать атрибут roles, то
можно будет указывать наименования групп пользователей, которым разрешен доступ.
В нашем случае мы разрешили доступ к Web-страницам пользователю с
регистрационным именем USerl и всем членам группы Administrators.
Теперь рассмотрим ситуацию с
запрещением доступа. Для установки перечня пользователей, которым доступ к
Web-страницам запрещен, используется тег <deny>. В примере мы использовали
все тот же параметр users, но для Него установили значение "*". Символ звездочки
в данном случае обозначает всех пользователей. Таким образом, доступ к
Web-страницам, располагающимся в зоне действия файла config.Web, разрешен только
перечисленным ранее пользователям, а всем остальным в доступе отказано.
Разработчик имеет возможность
указать права и для анонимных пользователей, т. е. не прошедших процедуру
аутентификации. Для обозначения анонимных пользователей используется значение
"?", т. е. вопросительный знак.
Естественно, для целей авторизации
следует более гибко использовать правила доступа. Например, некоторые
Web-страницы должны быть доступны анонимным пользователям, а остальные — нет. Но
если мы в единственном файле config.Web заранее откажем в доступе всем анонимным
пользователям, то они не смогут получить ни одной Web-страницы. Поэтому следует
использовать несколько конфигурационных файлов.
Как известно, изначально
конфигурационный файл создается в корневом каталоге Web-приложения, и его
действие распространяется на все остальные вложенные каталоги нижних уровней. Но
если в каком-либо вложенном каталоге создать свой конфигурационный файл
config.Web, то он будет перекрывать действие своего старшего собрата. Таким
образом, разработчик получает
возможность сгруппировать в различных каталогах файлы с одинаковыми правами
доступа и для каждого каталога создать свой конфигурационный файл.
Следующий
урок
|
