ASP.NET 2.0. Обзор новых сервисов, элементов управления и средств (2 часть)
Новшества в области администрирования
Еще один ощутимый недостаток ASP.NET, исправленный в ASP.NET 2.0, — полное отсутствие декларативных или программных интерфейсов, предназначенных для администрирования Web-сайтов. Раньше для изменения параметров конфигурации приходилось запускать Notepad и редактировать Machine.config или Web.config. С этим покончено. В ASP.NET 2.0 имеется развитой API администрирования, упрощающий чтение и запись параметров конфигурации. Кроме того, есть GUI администрирования, показываемый в браузере при запросе файла Webadmin.axd.
На момент написания статьи разработка Webadmin.axd еще не закончена. Он будет служить для конфигурирования различных сервисов, входящих в ASP.NET 2.0 (например сервисов управления членством и ролями), просмотра статистики Web-сайта и настройки параметров защиты.
Сервис управления членством
Одно из лучших новых средств ASP.NET 2.0 — сервис управления членством (membership service), предоставляющий удобный API для создания учетных записей пользователей и управления ими. С появлением ASP.NET 1.x началось массовое применение аутентификации на основе форм, но, чтобы применять такую аутентификацию на практике, по-прежнему приходилось писать довольно много кода. Сервис управления членством устраняет этот недостаток аутентификации на основе форм в ASP.NET 1.x и значительно упрощает написание кода аутентификации на основе форм.
Для работы с Membership API служат два новых класса: Membership и MembershipUser. Первый содержит статические методы для создания пользователей, их проверки и др. MembershipUser представляет отдельных пользователей и содержит методы и свойства для считывания и смены паролей, получения даты последнего входа и т. д. Например, следующий оператор принимает имя и пароль пользователя и возвращает true или false в зависимости от того, допустим ли этот пользователь. Такие операторы заменят вызовы использовавшихся в приложениях ASP.NET 1.x самодельных методов, которые проверяли удостоверения защиты через Active Directory или серверные базы данных:
Следующий оператор возвращает объект MembershipUser, представляющий пользователя с именем jeffpro:
MembershipUser user = Membership.GetUser ("jeffpro");
Наконец, следующий оператор считывает адрес электронной почты зарегистрированного пользователя (предполагается, что этот адрес был сохранен):
string email = user.Email;
Где хранятся имена пользователей, пароли и другие данные, c которыми работает сервис управления членством? Как и почти все сервисы ASP.NET 2.0, управляющие состоянием, этот сервис основан на провайдерах. Провайдеры — модули, позволяющие сервисам взаимодействовать с физическими источниками данных. В ASP.NET 2.0 будут входить провайдеры управления членством для баз данных Microsoft Access, SQL Server, службы каталогов Active Directory и, вероятно, для других источников данных. Вы можете написать собственные провайдеры для каких-либо источников данных. Роб Говард (Rob Howard), менеджер программы в группе Microsoft Web Platform and Tools детально рассмотрел эту тематику в статье «Nothin» But ASP.NET», доступной по ссылке http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp02182004.asp.
По умолчанию сервис управления членством использует провайдер Access и хранит данные о членстве в файле AspNetDB.mdb, находящемся в подкаталоге Data приложения. Можно выбрать другие провайдеры, указав их в разделе <membership> файла Web.config. Редактировать Web.config вручную необязательно, его можно изменить с помощью Webadmin.axd. Следующий фрагмент взят из Web.config после того, как через Webadmin.axd я создал базу данных SQL Server с именем WhidbeyLogin и настроил сервис управления членством на ее использование:
Атрибут connectionStringName ссылается на строку подключения, содержащуюся в новом разделе <connectionStrings> файла Web.config. В ASP.NET 2.0 эту часть Web.config можно зашифровать, чтобы защитить строки подключения к базе данных.
Область применения Webadmin.axd не ограничивается созданием баз данных и выбором провайдеров управления членством. Это средство годится для создания пользователей, управления удостоверениями защиты и для других целей. Webadmin.axd и Membership API предоставляют декларативные и программные средства управления зарегистрированными пользователями вашего сайта. Это огромный шаг вперед по сравнению с ASP.NET 1.x, где проблему управления удостоверениями приходилось решать в основном своими силами.
Элементы управления регистрацией
Сервис управления членством значительно сократил объем кода, необходимого для проверки регистрационных данных и управления пользователями. Но, кроме этого сервиса, введено новое семейство элементов управления, называемых элементами управления регистрацией (login controls), которые еще больше упростили аутентификацию на основе форм. Такие элементы можно использовать как совместно с сервисом управления членством, так и без него. Однако они настолько хорошо интегрируются с этим сервисом, что при совместном использовании сервиса управления членством и элементов управления регистрацией типичные задачи вроде проверки имен и паролей пользователей и отправки забытых паролей по электронной почте можно решать без единой строки кода. Во врезке «Новые элементы управления, планируемые в ASP.NET 2.0» дан список элементов управления регистрацией, которые предполагается включить в ASP.NET 2.0.
Элемент Login, показанный на рис. , — центральный элемент семейства. Он не только предоставляет гибко настраиваемый UI, но и может вызывать метод Membership.ValidateUser для проверки имени и пароля пользователя. Login также может вызвать метод FormsAuthentication.RedirectFromLoginPage, чтобы перенаправить пользователя на страницу, которую он пытался получить перед тем, как был направлен на страницу входа. Затем FormsAuthentication.RedirectFromLoginPage создает аутенификационные cookie. Позже я покажу, как работают Login и другие элементы управления регистрацией.
Диспетчер ролей
Сервис управления членством и элементы управления регистрацией были бы неполными без поддержки защиты на основе ролей. В ASP.NET 1.x, чтобы использовать роли при аутентификации на основе форм, приходилось писать код, сопоставляющий информацию о ролях каждому поступающему запросу. В ASP.NET 2.0 введен диспетчер ролей, применяемый отдельно или совместно с сервисом управления членством. Диспетчер ролей избавляет от необходимости писать такой код и упрощает авторизацию доступа пользователей к различным ресурсам, основанную на ролях.
Управление ролями опирается на провайдеры и активизируется в Web.config. У диспетчера ролей есть API, реализованный в новом классе Roles, содержащем такие методы, как CreateRole, DeleteRole и AddUserToRole. Важно отметить, что вы можете вообще не вызывать эти методы, поскольку Webadmin.axd полностью поддерживает создание ролей, их назначение пользователям и т. д. Достаточно один раз активизировать защиту на основе ролей, и дальше она «просто работает», используя заданную информацию о ролях и директивы авторизации URL в файлах Web.config, уже знакомые вам по ASP.NET 1.x.
Познакомившись с сервисом управления членством, элементами управления регистрацией и диспетчером ролей, вы, наверное, хотели бы увидеть пример использования этих трех средств. В примеры кода к этой статье, которые вы можете скачать, входит двухстраничное приложение, демонстрирующее аутентификацию на основе форм в стиле Visual Studio 2005. Чтобы развернуть приложение и посмотреть, как оно работает, сначала скопируйте файлы PublicPage.aspx, LoginPage.aspx и Web.config в виртуальный каталог вашего Web-сервера. Создайте в виртуальном каталоге подкаталог Secure и скопируйте в него ProtectedPage.aspx и еще один файл Web.config.
Запустите Webadmin.axd и настройте сайт на поддержку аутентификации на основе форм, сервиса управления членством и диспетчера ролей, выбрав провайдер по своему усмотрению. Создайте пользователей Bob и Alice и роли Manager и Developer. Назначьте пользователю Bob роль Manager, а Alice — роль Developer. (Я не буду перечислять все выполняемые для этого операции, поскольку они скорее всего изменятся еще до того, как вы прочитаете статью. К счастью, интерфейс средства Webadmin.axd вполне понятен интуитивно, и в Webadmin.axd есть мастера, помогающие выполнить настройку.)
Далее откройте PublicPage.aspx в браузере и щелкните кнопку View Secret Message, чтобы посмотреть ProtectedPage.aspx. ASP.NET перенаправит вас на LoginPage.aspx, в которой для запроса имени и пароля пользователя применяется элемент Login. Войдите, указав имя и пароль пользователя Bob. Страница ProtectedPage.aspx откроется в браузере, поскольку Bob имеет роль Manager, а файл Web.config в каталоге Secure разрешает доступ менеджерам. Заметьте: в элементе LoginName показывается имя пользователя, а в элементе LoginStatus — ссылка Log out. Наконец, закройте браузер, снова запустите его и откройте PublicPage.aspx. Щелкните View Secret Message и войдите как Alice. На этот раз вы не сможете открыть ProtectedPage.aspx, так как Alice не является менеджером.
Я использовал аналогичное приложение для обучения аутентификации на основе форм в ASP.NET 1.x, но для версии 1.x пришлось написать гораздо больше кода. Версия 2.0 заслуживает похвалы за краткость кода — особенно за то, что не нужно писать код проверки удостоверений, введенных в форму входа, или сопоставлять имена пользователей ролям. Если вы до сих пор сомневаетесь, попробуйте написать то же самое приложение в ASP.NET 1.x! Кроме того, посмотрите изменения, внесенные Webadmin.axd в Web.config. Помимо всего прочего, вы увидите элемент <roleManager>, который активизирует диспетчер ролей и обычно задает провайдер, используемый при управлении ролями.
Возможно, вас интересует, выполняется ли при каждом запросе обмен информацией между диспетчером ролей и базой данных, где хранятся роли. К счастью, нет. Диспетчер ролей хранит роли в cookie, причем шифрует их для конфиденциальности. В том невероятном случае, когда пользователю назначено так много ролей, что размера cookie не хватает для их хранения, cookie содержит список последних ролей, а запрос к базе данных применяется лишь при необходимости.
Персонализация
Еще одна новинка — сервис персонализации, предоставляющий готовое решение для хранения персональных параметров, задаваемых посетителями сайта. В настоящее время такие параметры обычно хранят в cookie, в серверных базах данных или и там, и там. Независимо от того, где они хранятся, ASP.NET 1.x мало чем помогает в этом случае. Приходится своими силами создавать и настраивать серверное хранилище этих данных и получать данные персонализации по именам пользователей, прошедших аутентификацию, по cookie или каким-то другим способом.
Сервис персонализации ASP.NET 2.0 облегчает хранение и считывание персональных параметров пользователей. Он основан на профилях пользователей. Профили определяются в Web.config с помощью нового элемента <profile>. Ниже приведен фрагмент файла Web.config:
В нем определен профиль, содержащий три свойства: Theme строкового типа, Birthday типа DateTime и LoginCount целого типа. Последнее по умолчанию равно 0.
В период выполнения можно обращаться к этим свойствам текущего пользователя через свойство Profile страницы, которое ссылается на экземпляр динамически скомпилированного класса со свойствами, заданными в профиле. Например, следующие операторы считывают значения свойств из профиля текущего пользователя:
Очевидным преимуществом персонализации является строгая типизация. Еще одно преимущество — то, что данные персонализации считываются и записываются по запросу. Этим они отличаются от состояния сеанса, которое загружается и сохраняется при каждом запросе независимо от того, используется оно или нет. Но, пожалуй, самое главное преимущество сервиса персонализации — не нужно явно задавать, где хранятся данные персонализации; система делает это за вас и хранит их постоянно. Когда эти данные потребуются, вы легко сможете обратиться к ним. В отличие от сеансов у профилей не истекает время ожидания.
Так где же хранятся данные персонализации? Возможны варианты. Сервис персонализации основан на провайдерах, поэтому его можно настроить на использование любого доступного провайдера. В ASP.NET 2.0 войдут минимум два провайдера персонализации: для Access и для SQL Server. Если не указано иное, сервис персонализации использует провайдер для Access, по умолчанию хранящий данные персонализации локально в DataAspNetDB.mdb. Вместо Access можно задействовать SQL Server, изменив Web.config вручную или через Webadmin.axd. Если вы не хотите хранить данные персонализации ни в Access, ни в SQL Server, пишите свой провайдер.
По умолчанию ASP.NET использует в качестве ключа к данным персонализации имя аутентифицированного пользователя, но можно настроить ASP.NET и на поддержку персонализации для анонимных пользователей. Прежде всего вы должны разрешить анонимную идентификацию, добавив в Web.config:
<anonymousIdentification enabled="true" />
Затем добавьте allowAnonymous=true в свойства профиля, которые вы хотите хранить для анонимных пользователей:
<name="Theme" allowAnonymous="true" />
Теперь свойство Theme будет доступно как персональный параметр независимо от того, прошли ли аутентификацию пользователи, которые обращаются к вашему сайту.
По умолчанию при анонимной идентификации, чтобы идентифицировать пользователей, повторно посещающих сайт, используются cookie. С помощью атрибутов, указываемых в <anonymousIdentification>, можно различными способами настроить эти cookie. Например, задать имя cookie и указать, надо ли шифровать содержимое cookie. Или настроить сервис персонализации на анонимную аутентификацию без cookie, при которой для идентификации пользователя, повторно посещающего сайт, применяется передача идентификатора сеанса через URL (URL munging). Предусмотрена даже возможность автоматического определения: если выполняющий запрос браузер поддерживает cookie, используются cookie, а в ином случае идентификатор сеанса передается в URL.
Чтобы посмотреть, как работает персонализация, запустите один из примеров кода к статье — Personalize.aspx. Эта страница позволяет каждому посетителю сайта выбрать тему, затем запоминает ее и применяет всякий раз, когда посетитель возвращается на сайт. Заметьте: тема программно применяется к странице в PreInit — новом событии, которое происходит перед Init.
Перед запуском примера разрешите анонимную аутентификацию и определите профиль, содержащий строковое свойство Theme. Следующий фрагмент кода из файла Web.config показывает, как решить эти две задачи:
Еще одна возможность, которой сильно не хватало в ASP.NET 1.x, — поддержка зависимостей кэша от базы данных. Элементы, помещаемые в кэш приложения ASP.NET, могли зависеть от других кэшированных элементов или объектов файловой системы, но не от записей базы данных. В ASP.NET 2.0 этот недостаток исправлен введением зависимостей кэша от SQL-данных (SQL cache dependencies).
Зависимости кэша от SQL-данных представляются экземплярами нового класса SQLCacheDependency. Применять их — проще некуда. Следующий оператор вставляет DataSet с именем ds в кэш приложения и создает зависимость между DataSet и таблицей Products базы данных Northwind:
Cache.Insert ("ProductsDataSet", ds, new SqlCacheDependency ("Northwind", "Products");
Если содержимое таблицы Products изменится, ASP.NET автоматически удалит DataSet.
Зависимости кэша от SQL-данных можно использовать и в кэше вывода ASP.NET. Следующая директива указывает ASP.NET, что вывод страницы, содержащей данные, кэшируется до тех пор, пока не изменится содержимое таблицы Products или пока не пройдет 60 секунд (смотря что случится раньше):
Зависимости кэша от SQL-данных можно использовать при работе с SQL Server 7.0, SQL Server 2000 и с будущей версией SQL Server 2005. SQL Server 2005 будет поддерживать зависимости кэша от SQL-данных без какой-либо предварительной настройки, а SQL Server 7.0 и SQL Server 2000 для поддержки этих зависимостей придется соответствующим образом сконфигурировать. Конфигурирование заключается в создании триггеров базы данных и специальной таблицы, к которой ASP.NET обращается, чтобы определить, внесены ли изменения. Эта таблица периодически опрашивается фоновым потоком через интервал, который задается при настройке и по умолчанию равен пяти секундам. В SQL Server 2005, чтобы определить, внесены ли изменения, не потребуются ни специальная таблица, ни периодический опрос. Кроме того, зависимости кэша от данных SQL Server 2005 можно применять на уровне записей, а зависимости кэша от данных SQL Server 7.0 ;или SQL Server 2000 работают на уровне таблиц. Чтобы настроить базу данных на поддержку зависимостей кэша от SQL-данных, можно воспользоваться утилитой Aspnet_regsqlcache.exe или Webadmin.axd.
Новая модель динамической компиляции
Одно из многих новшеств ASP.NET 1.x заключалось в том, что система могла компилировать код при первом обращении к нему. Однако автоматически компилировались только страницы, а вспомогательные классы, такие как компоненты доступа к данным, приходилось компилировать отдельно.
ASP.NET 2.0 расширяет модель динамической компиляции: теперь практически все можно компилировать автоматически. Каталог bin по-прежнему существует для обратной совместимости, но теперь его дополняют каталоги Code и Resources. Файлы с кодом на C# и Visual Basic в каталоге Code и файлы .resx и .resource в каталоге Resources автоматически компилируются ASP.NET и кэшируются в системных подкаталогах. Более того, WSDL-файлы (Web Services Description Language), скопированные в каталог Code, компилируются в прокси Web-сервисов, а XSD-файлы (XML Schema Definition Language) — в типизированные DataSet. Отредактировав файл Web.config, можно расширить применение этих каталогов, настроив поддержку динамической компиляции для других типов файлов.
Предкомпиляция и развертывание без исходного кода
Когда речь заходит о динамической компиляции, один из наиболее часто задаваемых вопросов по ASP.NET 1.x — можно ли заранее компилировать страницы, чтобы при первом обращении к странице не было задержки из-за затрат времени на компиляцию. Сам по себе вопрос не совсем корректен (задержка минимальна и связанные с ней издержки пренебрежимо малы, если принять во внимание, что потом выполняются тысячи или даже миллионы запросов). Тем не менее Microsoft посчитала своим долгом сделать кое-что, чтобы облегчить жизнь разработчикам. Это «кое-что» — возможность заранее скомпилировать все страницы приложения, отправив запрос фантомному ресурсу precompile.axd.
Но это еще не все, что сделано в области предкомпиляции. Еще одна широко востребованная возможность — способность заранее компилировать все приложения в управляемые сборки, которые допускается развертывать без исходного кода, что особенно удобно при хостинге. В ASP.NET 2.0 введена новая утилита командной строки — Aspnet_compiler.exe, которая выполняет предкомпиляцию и развертывание без исходного кода; в Visual Studio 2005 войдет аналогичное средство. Следующая команда выполняет предкомпиляцию приложения в каталоге Web1 и развертывает его без исходного кода в каталоге Web2:
Aspnet_compiler -v /web1 -p c:web1 c:web2
После выполнения команды каталог назначения содержит пустые файлы ASP.NET (ASPX, ASCX, ASIX и т. д.) и копии любого статического содержимого исходного каталога: HTML-файлы, .config-файлы и файлы изображений. Развертывание без исходных текстов не обеспечивает «железную» защиту вашей интеллектуальной собственности (поскольку квалифицированный сотрудник Интернет-провайдера все равно сможет разобраться в вашем приложении, декомпилировав сгенерированные сборки), но значительно поднимает барьер перед обычными взломщиками кода.
Новая модель разделения кода
ASP.NET 1.x поддерживает две программные модели: встраиваемого кода (inline model), в которой HTML и код сосуществуют в одном ASPX-файле, и отделенного (codebehind model), где HTML хранится отдельно в ASPX-файле, а код содержится в файлах исходного кода (например в C#-файлах). В ASP.NET 2.0 вводится третья модель: новая форма отделенного кода, основанная на поддержке частичных классов компиляторами Visual C# и Visual Basic .NET. Новая модель призвана исправить неприятный недостаток исходной модели; он заключался в том, что традиционные классы отделенного кода должны были содержать защищенные поля, чьи имена и типы сопоставляются элементам управления, объявленным в ASPX-файле.
В листингах 710 и 8 показано, как работает новая модель отделенного кода. Hello.aspx содержит декларативную часть страницы, а Hello.aspx.cs — код. Обратите внимание на атрибут CompileWith в директиве @ Page. Также заметьте, что в классе MyPage отсутствуют какие бы то ни было поля, сопоставляемые элементам управления, объявленным в ASPX-файле. Старая модель отделенного кода по-прежнему поддерживается, но в дальнейшем предпочтение будет отдаваться новой модели. Не удивительно, что в Visual Studio 2005 будет встроена поддержка новой модели разделения кода.
Листинг 7. Модель отделенного кода. Файл Hello.aspx
Одна из моих любимых функций ASP.NET 2.0 — «облегченный» возврат формы («lightweight» postback), обеспечиваемый клиентским диспетчером обратных вызовов. Раньше страницы ASP.NET, чтобы вызвать код на стороне сервера, должны были возвратить форму серверу. Возвраты формы неэффективны, так как возвращаются все данные, сгенерированные элементами управления страницы. Кроме того, при возврате формы выполняется актуализация страницы, что вызывает неприятное мигание.
В ASP.NET 2.0 вводится клиентский диспетчер обратных вызовов, позволяющий страницам выполнять обратные вызовы сервера без полного возврата формы. Обратные вызовы асинхронны и выполняются с использованием XML-HTTP. В их данные не включаются возвращаемые данные (postback data), и они не приводят к актуализации страницы. (На серверной стороне до события PreRender страница обрабатывается, как обычно, но затем обработка прекращается, поэтому HTML-данные заново не отображаются.) При этом браузер должен поддерживать протокол XML-HTTP, т. е. нужен Microsoft Internet Explorer версии 5.0 или выше.
Для использования клиентского диспетчера обратных вызовов требуется выполнить три операции. Во-первых, вызовите Page.GetCallbackEventReference, чтобы получить функцию, вызываемую из клиентского сценария для обратного вызова сервера по протоколу XML-HTTP. ASP.NET вернет имя и реализацию этой функции. Во-вторых, напишите метод клиентского сценария, вызываемый, когда обратный вызов возвращает управление. Имя метода — один из аргументов, передаваемых GetCallbackEventReference. В-третьих, реализуйте в странице интерфейс ICallbackEventHandler. В нем содержится единственный метод RaiseCallbackEvent, вызываемый на стороне сервера, когда выполняется обратный вызов. Строка, возвращаемая RaiseCallbackEvent, передается методу, о котором говорилось в описании предыдущей операции.
Код в листинге 9 показывает, как работают клиентские обратные вызовы, и демонстрирует одно из наиболее типичных практических применений таких вызовов. Страница выводит форму, запрашивающую имя и адрес. Введите ZIP-код 378xx или 379xx в поле Zip Code и щелкните кнопку Autofill — в поле City появится название города. Страница обращается к серверу, чтобы получить название города, причем для этого выполняется клиентский обратный вызов, а не полный возврат формы. На практике для преобразования ZIP-кода в название города скорее всего выполнялся бы запрос к базе данных. Заметьте: страница не перерисовывается в отличие от ситуаций, когда используется возврат формы серверу. Информация на странице обновляется быстро и корректно!
<script language="javascript"> // Функция, вызываемая, когда обратный вызов возвращает управление function __onCallbackCompleted (result, context) { // Показываем в поле ввода "City" строку, // возвращаемую методом RaiseCallbackEvent сервера document.getElementById (City).value = result } </script>
// Связываем событие обратного вызова с кнопкой Autofill // через атрибут onclick (и добавляем "return false" в код // события, чтобы не было возврата формы) AutofillButton.Attributes.Add ("onclick", cbref + "; return false;"); }
// Обработчик события обратного вызова на серверной стороне string ICallbackEventHandler.RaiseCallbackEvent (string arg) { if (arg.StartsWith ("378")) return "Oak Ridge"; else if (arg.StartsWith ("379")) return "Knoxville"; else return "Unknown"; } </script>
Заключение
В ASP.NET 2.0 много других новых средств, не рассмотренных в статье. Например, встроенный сервис ведения статистики сайта (site-counter service) позволяет вести статистику использования сайта и просматривать ее в Webadmin.axd или в GUI собственной разработки. Новая подсистема Web Parts предоставляет инфраструктуру для разработки порталов в стиле SharePoint Server. Интегрированная поддержка мобильных устройств означает, что больше не придется устанавливать отдельный инструментальный набор, чтобы адаптировать вывод к PDA и другим устройствам с небольшим объемом памяти. Внесена масса усовершенствований в существующие элементы управления, благодаря чему они стали более гибкими средствами разработки Web-страниц, основанных на компонентах.
Пора уже сейчас приступать к ознакомлению с ASP.NET 2.0: зная, что появится в новой версии (и что не появится), вы сможете уже сегодня планировать архитектуру, на которую будет легко перейти завтра. Ваши приложения для ASP.NET 1.x должны работать в версии 2.0 без изменений, поскольку Microsoft пообещала, что обеспечит совместимость со старой платформой. Но будущее принадлежит ASP.NET 2.0, и в этом будущем вы сможете получить более мощную функциональность с меньшими усилиями. Неужели вы этому не рады?
