В данной лекции описываются параметры, доступные в группе разделов <System.Web>. Эта группа содержит большое количество параметров для настройки ASP.NET – и все они рассмотрены здесь. Большую часть своего времени вы потратите, работая именно с этой группой разделов. В лекции рассмотрены следующие разделы.

• <authentication>. Раздел настраивает тип аутентификации, используемой для ваших приложений ASP.NET.
• <authorization>. Раздел настраивает авторизацию ваших веб-приложений. Авторизация – это процесс определения того, можно ли разрешить пользователю доступ к какому-либо ресурсу.
• <browserCaps>. Раздел определяет возможности браузера. Для определения типа браузера, используемого для доступа к вашему веб-приложению, служит компонент браузера.
• <clientTarget>. Раздел, основанный на коллекции, содержит псевдонимы, которые связаны с конкретным агентом пользователя. Эти псевдонимы заставляют страницу отображаться в конкретном браузере.
• <compilation>. Раздел одержит параметры для настройки компиляции страниц ASP.NET. Используйте его для добавления новых языков программирования, работающих совместно с ASP.NET.
• <customErrors>. Раздел настраивает сообщения об ошибках, отсылаемые пользователям.
• <globalization>. Раздел настраивает параметры глобализации сервера или приложения.
• <httpHandlers>. Раздел настраивает и добавляет обработчики HTTP – классы, которые обрабатывают запросы к различным расширениям файлов.
• <httpModules>. Раздел настраивает и регистрирует дополнительные модули HTTP. Они используются для выполнения операций HTTP-запроса перед тем, как его обработает обработчик HTTP.
• <httpRuntime>. Раздел содержит параметры для настройки среды выполнения HTTP.
• <identity>. Раздел настраивает и реализует заимствование прав для ваших веб-приложений.
• <machineKey>. Раздел настраивает ключи шифрования, используемые другими разделами.
• <pages>. Раздел содержит параметры настройки страниц для всех страниц, на которые влияет настроечный файл.
• <processModel>. Раздел содержит параметры для настройки расширения ISAPI ASP.NET. При работе в Windows Server 2003 этот раздел не используется.
• <securityPolicy>. Раздел объявляет отображение именованных уровней безопасности на правильные файлы политик безопасности.
• <sessionState>. Раздел настраивает способ сохранения информации о сессии вашего веб-приложения.
• <trace>. Раздел настраивает поведение службы трассировки ASP.NET.
• <trust>. Раздел настраивает уровень безопасности, с которым выполняется приложение.
• <webControls>. Раздел настраивает место расположения файла сценария проверки на стороне клиента.
• <webServices>. Раздел содержит параметры настройки веб-службы XML, созданные с помощью ASP.NET.

Работа с разделом <authentication>

Аутентификация – это процесс определения (идентификации) пользователя, который пытается получить доступ к приложению. Аутентификация не определяет, имеет ли пользователь право доступа к данному ресурсу; это делает раздел <authorization> системной группы <System.Web>. Аутентификация только определяет пользователя, чтобы предоставить (или нет) ему доступ к запрошенному ресурсу. Аутентификация играет огромную роль в разработке приложений ASP.NET, и сейчас вы познакомитесь с настройкой метода аутентификации, используемого в ваших приложениях.

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

• Аутентификация Windows. Этот метод аутентификации основан на проверке пользователя системой Microsoft Windows. Windows при доступе пользователя к сайту запрашивает имя пользователя и пароль, а затем сверяет эти данные со списком пользователей Windows. Метод очень популярен во внутренних сетях, так как большинство пользователей уже имеют в домене учетные записи, которые могут быть использованы для аутентификации.
• Аутентификация при помощи формы. Этот метод аутентификации использует базовую форму ASP.NET, принимающей имя пользователя и пароль, которые можно сверить с базой данных или файлом XML. Этот метод популярен на интернет-сайтах, так как он не использует базу данных пользователей операционной системы.
• Паспорт. Этот метод аутентификации позволяет пользователям входить на сайт с помощью их паспорта Microsoft Passport. Microsoft Passport – это имя пользователя и пароль (администрируемые Microsoft), которые могут быть использованы на различных сайтах.

Для настройки аутентификации для вашего приложения вы будете работать с разделом <authentication>, расположенном в группе разделов <System.Web>. Он содержит большое количество параметров и элементов, используемых для настройки аутентификации приложения. В отличие от большинства разделов в <System.Web> его можно использовать только в файле web.config вашего главного приложения; его нельзя настроить для отдельной директории или файла.

Настройка режима аутентификации

Первым шагом в настройке аутентификации приложения является установка режима аутентификации. Для этого используйте свойство mode элемента <authentication>, например:

Свойство mode имеет несколько значений, используемых для установки различных режимов аутентификации (см. табл. 4.1).

Настройка режима аутентификации для использования аутентификации Windows

Первым шагом к установке режима аутентификации Windows является добавление в файл web.config следующей строки.

Это единственное изменение, которое необходимо сделать в файле web.config. Следующим шагом является установка используемого метода аутентификации Windows. Для настройки аутентификации Windows вы будете работать с инструментом администрирования IIS. Он позволит задать аутентификации Windows типа Basic, Digest или Integrated. Данный раздел посвящен использованию настроечных файлов, поэтому я не буду описывать, как настраивать аутентификацию Windows в инструменте администрирования IIS. Об этом подробно говориться в лекции 8.

Настройка режима аутентификации для аутентификации с помощью формы

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

Следующий шаг включает новый элемент, который используется в разделе <authentication> – элемент <forms>. Он содержит свойства, которые следует настроить, прежде чем использовать аутентификацию с помощью формы. Данные параметры настраивают cookie аутентификации, который проверяет пользователя, например:

Таблица 4.2 содержит перечень свойств, описаний и возможных значений элемента <forms>.

Ниже приведен пример элемента <forms>.

В этом примере имя cookie устанавливается равным .SiteCookie, URL страницы входа в значение – login.aspx, а уровень защиты – all. Установка уровня защиты в значение all означает, что cookie будет защищен как при помощи проверки данных, так и с помощью шифрования. Время истечения действия cookie устанавливается в 30 минут, путь равен "/", и SSL не требуется. Сдвигающееся время действия установлено в значение true, то есть при каждом запросе время действия cookie будет отсчитываться заново.

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

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

Субэлемент <credentials> элемента <forms> содержит список имен пользователей и паролей, используемых для аутентификации пользователей. Это не единственная возможность создания списка имен пользователей и паролей, но она является самым простым методом и полезна для сайтов с небольшим и редко меняющимся списком пользователей и паролей. Чтобы использовать раздел <credentials>, сначала установите свойство passwordFormat элемента <credentials>, например:

Таблица 4.3 содержит список доступных значений свойства passwordFormat.

После указания метода сохранения паролей, пары имен пользователей и паролей можно сохранить раздел <credentials> с помощью элемента <user>, например:

Свойство name – это имя пользователя, а свойство password – зашифрованный пароль пользователя. Вы можете сохранить группу имен пользователей и паролей в разделе <credentials>, а затем сверять их с этой группой из вашего приложения.

Реализация аутентификации при помощи формы

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

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

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

C#

VB.NET

Давайте построчно разберем этот код.

Сначала выполняется проверка того, совпадают ли введенные имя пользователя и пароль с сохраненными именем пользователя и паролем. В нашем примере имена пользователей и пароли хранятся в настроечном файле, поэтому для сравнения данных используется метод FormsAuthentication.Authenticate(). В больших и более сложных приложениях имена пользователей и пароли необходимо сохранять в базе данных, в которой их можно быстро изменить. В этом случае следует создать метод поиска в базе совпадающей пары и возвращения значение true или false. Этот метод можно использовать вместо метода FormsAuthentication.Authenticate(), и наш пример будет прекрасно работать. Если метод FormsAuthentication.Authenticate() или ваш собственный возвращают значение true, выполняется следующая строка кода.

Она вызывает метод FormsAuthentication.RedirectFromLoginPage(), который возвращает пользователя к запрашиваемой странице (странице, с которой пользователь был перенаправлен на страницу регистрации, хранящейся в параметре строки запроса ReturnURL), а если такой страницы нет, то к странице default.aspx. Первый передаваемый параметр – имя пользователя, а второй – логическое значение, указывающее, следует ли сохранить cookie аутентификации. Если второе значение равно true, cookie сохраняется на неопределенный срок, в противном случае срок действия cookie истекает через время, установленное в настроечном файле. Если метод FormsAuthentication.Authenticate() или собственный метод аутентификации возвращают false, дайте пользователю знать, что он должен войти заново.

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

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

Настройка аутентификации с помощью паспорта

Последним описываемым типом аутентификации является аутентификация с помощью Microsoft Passport. Microsoft Passport – это единые имя пользователя и пароль, с помощью которых пользователь может получить доступ к сайтам в интернете. Этот метод аутентификация уже используется большим количеством компаний, включая CitiBank и Monster.com. Хотя предоставление такой возможности вашим посетителям великолепно, она требует лицензирования, которое может оказаться слишком дорогим для небольших сайтов. Кроме того, этот тип аутентификация не является подходящим для сайтов интранет, на которых можно легко использовать аутентификацию Windows. Первым шагом в настройке аутентификации с использованием паспорта является установка режима аутентификации в значение Passport.

Раздел аутентификации включает элемент <passport>, который содержит единственное свойство с именем redirectURL. Свойство redirectURL используется для указания страницы, на которой пользователь регистрируется. Этот URL должен указывать на страницу входа Passport, которая проверяет пользователей сайта. Ниже приведен синтаксис элемента <passport>.

Если неопознанный пользователь попытается получить доступ к защищенной части веб-приложения, он будет перенаправлен на URL, указанный в свойстве redirectURL. Это единственный настроечный параметр, который требуется для установки аутентификации Passport.

Ключевые моменты <authentication>

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

• Вы можете установить свойство mode раздела аутентификации на использование аутентификации Windows с помощью форм или с помощью паспорта.
• Вы настраиваете параметры аутентификации Windows с помощью инструмента администрирования IIS.
• Метод аутентификации с помощью формы использует для настройки различных параметров cookie аутентификации элемент <forms>.
• Вы можете настроить и реализовать в приложении аутентификацию с помощью формы, использовав форму ASP.NET и небольшой фрагмент кода .NET.
• Метод аутентификации с помощью паспорта использует для настройки расположения страницы регистрации паспорта элемент <passport>.

Работа с разделом <authorization>

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

Имеется два элемента, используемых в разделе <authorization>: <allow> и <deny>. Они предоставляют или запрещают доступ к ресурсу на основе имени пользователя, роли или того, как производится доступ к ресурсу. Процесс ASP.NET предполагает, что пользователь может получить доступ к ресурсу, и если нет правила, запрещающего доступ для этого пользователя, то доступ будет разрешен.

Ниже приведен синтаксис для использования элементов <allow> и <deny>.

Оба элемента имеют одинаковые свойства (см. табл. 4.4).

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

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

Пример из практики. Возможность включать в свойство users пользователей домена полезна при создании сайта интранет. Если пользователи уже зарегистрировались в домене, и применяется аутентификация Windows, то легко настроить безопасность приложения, не используя дополнительные имена пользователей или пароли. Пользователи просто должны включить перед именем пользователя имя домена, за которым следует обратная косая черта (\) (mydomain\James).

Свойство roles предоставляет или запрещает доступ на основе роли пользователя. Ниже приведен пример использования ролей для предоставления доступа.

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

Другой опцией для предоставления и запрета доступа для пользователей является свойство verb. Оно предоставляет или запрещает доступ на основе того, как пользователь пытается получить доступ к приложению – с помощью методов HTTP GET, POST, HEAD или DEBUG. Ниже приведен пример предоставления доступа POST для администратора и запрета его для всех остальных пользователей.

В примере пользователи группы Admins (Администраторы) системы Windows имеют право на использование POST для приложения; для всех остальных пользователей при попытке применения POST для приложения доступ будет запрещен.

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

В этом примере единственным пользователем, который получит доступ к файлу admin.aspx, является пользователь, определенный как Administrator. Использование тега location является единственным способом, с помощью которого права доступа можно применить к отдельному файлу.

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

Можно применить права доступа к поддиректории приложения – для чего существуют два метода.

• Используйте тег location так, как показано в примере, и укажите список имен директорий в свойстве path.
• Добавьте в поддиректорию файл web.config и включите в него права доступа.

Файловая авторизация

До сих пор обсуждалась авторизация на основе запросов, но есть другой тип авторизации, который можно использовать в ASP.NET. При аутентификации Windows, если пользователь пытается получить доступ к файлу .aspx или .asmx, процесс ASP.NET выполняет проверку списка управления доступом (access control list – ACL) на предмет того, имеет ли этот пользователь право на доступ к этому файлу. То есть ASP.NET, кроме проверки того, имеет ли пользователь право на запрос к данному URL, определяет, имеет ли пользователь права NTFS для доступа к данному файлу. Это дает дополнительную возможность ограничить доступ пользователей к отдельным файлам, но такая возможность существует только при использовании аутентификации Windows.

Ключевые моменты <authorization>

Авторизация критически важна для обеспечения безопасности ваших приложений. Авторизация ASP.NET основана на URL, к которому пользователь осуществляет доступ, и комбинации правил <allow> и <deny> из раздела настроек. Ниже приведены ключевые моменты, которые нужно помнить при работе с разделом <authorization>.

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

Работа с разделом <browserCaps>

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

Файл machine.config содержит в разделе <browserCaps> большое количество информации. Cюда входят регулярные выражения и параметры для многих браузеров и мобильных устройств. Такую информацию опубликовала компания cyScape, и в будущем предусмотрите возможность обновить ее на веб-сайте http://www.cyscape.com/browsercaps. (В настоящее время обновлений нет.) Эта компания публикует программное обеспечение для определения браузера – BrowserHawk. Имеются обновления для той части раздела, который содержит информацию о мобильных элементах управления. За дополнительными сведениями об обновлении мобильных элементов управления обратитесь к лекции 5.

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

Элементы, входящие в раздел <browserCaps>

Имеется несколько элементов, которые можно использовать в разделе <browserCaps>. Первым из них является элемент <result>. Он определяет имя класса, хранящего информацию, полученную из раздела <browserCaps>. Ниже показан элемент <result> из файла machine.config сервера.

Свойство type указывает на класс, который хранит все пары имя/значение. Класс, на который указывает тег result, может использоваться процессом ASP.NET для чтения значений и настройки вывода HTML.

Раздел <browserCaps> использует серверные переменные IIS, взятые из заголовка запроса HTTP. Элемент <use> определяет серверную переменную, которая будет источником информации, например:

Здесь показано, что информация о возможностях браузера берется из серверной переменной IIS HTTP_USER_AGENT. Свойство as делает серверную переменную доступной для всех остальных разделов. В этом примере в разделе <browserCaps> есть ссылка на переменную Agent и чтение из этой серверной переменной данных. Далее я опишу пару используемых для этого способов, но сперва рассмотрим другие элементы из раздела <browserCaps>.

Сердцем раздела <browserCaps> является элемент <filter>. Он ищет соответствия текста, содержащегося в серверных переменных, регулярным выражениям, а затем создает список параметров браузера, который должен быть включен в класс браузера. Ниже приведен синтаксис элемента <filter>.

Регулярное выражение в свойстве match сравнивается со строкой из свойства with. Если свойство with не объявлено, то используется строка в выражении <use>. Если соответствие между регулярным выражением из свойства match и строкой, содержащейся в свойстве with либо в операторе <use>, найдено, то пара имя/значение включается в класс возможностей браузера и генерируется корректный HTML, отправляемый клиенту. Элемент <filter> включает субэлемент с именем <case>. Элемент <case> используется аналогично элементу <filter> и содержит свойства match и with, которые сопоставляют строку с регулярным выражением. Элемент <case> используется аналогично оператору case из VB. В элемент <filter> можно включить несколько элементов <case>. При обнаружении совпадения в операторе <case> пропускаются остальные операторы <case> из этой группы. Ниже приведен синтаксис элемента <case>.

Используется первый элемент <case>, который находит совпадение, а остальные элементы case игнорируются. Это несколько непонятно, так что давайте посмотрим на пример.

Этот пример не имеет объявления свойства with, так что элементы <case> будут искать строку, объявленную в последнем элементе <use>. В данном случае эта строка является серверной переменной HTTP_USER_AGENT. Вот как обрабатывается элемент <filter>.

1. Обрабатывается первый case и производится поиск в переменной HTTP_USER_AGENT на предмет того, содержится ли в ней строка "Windows 95" или "Win95".
2. Если эта строка содержит одно из этих значений, то пара имя/значение из элемента <case> добавляется в класс возможностей браузера, указанный в элементе <result>.
3. Если совпадение найдено, то все остальные элементы <case> не обрабатываются и обработка элемента <filter> завершается.
4. Если совпадение не найдено, то обрабатывается следующий элемент <case>, и вся процедура повторяется. Если совпадений не найдено, элемент <filter> завершается без добавления в класс пары имя/значение, и начинается обработка следующего элемента <filter>.

В этом процессе обработчик раздела проходит по разделу <browserCaps> фильтр за фильтром и case за case до тех пор, пока класс возможностей браузера не заполнится парами имя/значение, которые описывают браузер или устройство, используемое для доступа к ресурсу. Чтобы лучше это себе представить, давайте посмотрим на более сложный элемент <filter>, взятый непосредственно из файла machine.config.

Это один из наиболее сложных элементов <filter>, чье назначение состоит в определении того, является устройство, получающее доступ, устройством Nokia. Если это устройство Nokia, элемент <filter> извлекает из серверной переменной gatewayVersion, gatewayMajorVersion и gatewayMinorVersion. Эта информация добавляется в класс возможностей браузера и используется при создании HTML для отправки в браузер. Есть пара соглашений, используемых в этом операторе <filter>, которые не использовались в предыдущих операторах <filter> (большинство из них работает с регулярными выражениями). Я опишу каждое из них при рассмотрении оператора <filter>. Первый элемент в этом примере – это элемент <use>.

Этот элемент делает серверную переменную HTTP_VIA доступной для элементов <filter> как переменную via. Элемент <use> необходим, так как информация, которую вы ищете, содержится не в серверной переменной по умолчанию HTTP_USER_AGENT, а в переменной HTTP_VIA. Первые элементы <filter> и <case> таковы:

Первый оператор <case> производит поиск строки Nokia в переменной via. Если строка Nokia в переменной via найдена, обрабатываются элементы <filter> и <case> внутри этого оператора <case>. Вот как выглядят элементы <filter> и <case>, включенные в этот оператор.

Оператор <case> в этом примере ищет несколько различных переменных и делает их доступными для класса возможностей браузера, который будет настраивать HTML, отправляемый в браузер.

Если просмотреть раздел <browserCaps> файла machine.config, то можно обнаружить множество различных элементов <filter> и <case>, похожие на показанный только что. Количество информации в нем поражает; он дает ASP.NET возможность настраивать HTML для большого количества браузеров и мобильных устройств.

Ключевые моменты <browserCaps>

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

• Раздел <browserCaps> настраивает вывод HTML на основе браузера или мобильного устройства, который получает доступ к ресурсу.
• Раздел <browserCaps> использует для определения того, какой браузер или мобильное устройство получает доступ к ресурсу, доступные для него серверные переменные из заголовка запроса HTTP.
• Для выделения из запрошенных переменных строк, по которым определяется, помимо всего прочего, версия браузера и его возможности, используются регулярные выражения.
• Обновления этой информации скоро должны быть доступны на сайте http://www.cyscape.com/browserCaps

Работа с разделом <clientTarget>

Для большинства страниц, которые вы создаете с помощью ASP.NET, можно положиться на идентификацию браузера, выполняемую ASP.NET и разделом <browserCaps>, но иногда возникает ситуация, когда нужно предназначить страницу для определенного браузера. Здесь на сцену выходит раздел <clientTarget>. Раздел <clientTarget> содержит определенное количество псевдонимов браузеров, которые используются для генерации содержимого, предназначенного для конкретного браузера. Каждый псевдоним содержит значение userAgent, представляющее целевой браузер. Значение userAgent – это строка, которая находится в серверной переменной userAgent при доступе пользователя к приложению. Этот раздел по своей работе похож на разделы <appSettings> и <configSections>, и вы можете добавлять сюда новые псевдонимы, удалять их и очищать весь раздел. Ниже приведен раздел <clientTarget> по умолчанию из файла machine.config.

Каждый псевдоним добавляет в коллекцию и связывается с конкретным значением userAgent. Первые два псевдонима относятся к браузерам класса Internet Explorer 4 или 5. Эти целевые браузеры очень похожи, если не одинаковы, так как используют высокоуровневый псевдоним целевого браузера. Высокоуровневый псевдоним заставляет страницу отображать элементы управления ASP.NET с помощью высокоуровневых настроек. Следующим типом псевдонимов является низкоуровневый псевдоним, который заставляет страницу отображать элементы управления ASP.NET в низкоуровневом режиме.

Высокоуровневые и низкоуровневые псевдонимы

В зависимости от того, установлен ли параметр clientTarget в значение uplevel или downlevel, различается отображение элементов управления ASP.NET. Низкоуровневый браузер понимает только HTML версии 3.2. Если вы предназначаете страницу для низкоуровневого псевдонима, страница при отправке HTML в браузер будет использовать только HTML 3.2. Высокоуровневый браузер или устройство должны уметь обрабатывать следующие технологии.

• ECMAScript версии 1.2 (JScript, JavaScript)
• HTML 4.0
• CSS
• The Microsoft Document Object Model (MSDOM)

Когда вы назначаете страницу для высокоуровневого браузера, страница будет отображаться с использованием CSS, HTML 4.0, ECMAScript 1.2 и MSDOM, извлекая все возможные преимущества от применения целевого браузера. Примерами высокоуровневых браузеров являются Internet Explorer 4.0 и выше.

Использование целевых клиентов в своих страницах

Предназначить свои страницы для конкретного целевого псевдонима очень просто. Каждая страница ASP.NET имеет вверху директиву @page, а директива @page имеет свойство clientTarget. Это свойство можно установить в значение псевдонима, который имеется в коллекции <clientTarget>, и страница будет отображаться с использованием этого псевдонима. Ниже показан пример использования свойства clientTarget.

Страница будет отображаться с использованием только низкоуровневых технологий – HTML 3.2. Данный параметр переопределяет любую идентификацию браузера, выполняемую ASP.NET и разделом <browserCaps>.

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

Добавление и удаление псевдонимов

Добавлять и удалять псевдонимы в раздел <clientTarget> очень просто, так как для этого используются те же элементы, что и для раздела <appSettings>. Ниже приведен синтаксис добавления в раздел <clientTarget> псевдонимов.

Свойство alias используется в свойстве clientTarget страницы ASP.NET. Свойство userAgent отражает серверную переменную userAgent, которая должна отправляться браузером. Если вы хотите добавить новый псевдоним для какого-либо браузера, вы получаете серверную переменную userAgent при доступе браузера к вашему сайту, а затем используете ее значение для добавления псевдонима для целевого браузера. Ниже показано, как удалять псевдоним, ранее определенный в разделе <clientTarget>.

Удаление псевдонима из коллекции сделает этот псевдоним недоступным для всех страниц, на которые распространяется этот настроечный файл. Аналогично разделу <appSettings>, можно также использовать элемент <clear>, который удаляет все ранее добавленные в этот раздел псевдонимы. Ниже приведен синтаксис элемента <clear>.

Ключевые моменты <clientTarget>

Раздел <clientTarget> позволяет обходить обнаружение браузера ASP.NET по умолчанию и предназначать свои страницы для конкретного браузера или группы браузеров. Ниже приведены ключевые моменты, относящиеся к разделу <clientTarget>.

• Раздел <clientTarget> работает аналогично разделу <appSettings> в том, что вы можете использовать элементы <add>, <remove> и <clear> для добавления, удаления псевдонимов и полной очистки коллекции.
• Вы можете использовать свойство clientTarget директивы @page, чтобы страница отображалась в конкретном браузере, отличном от того, который определила система ASP.NET.

Работа с разделом <compilation>

Раздел <compilation> включает несколько параметров и элементов для настройки способа компиляции ASP.NET. Можно использовать различные элементы для добавления новых компиляторов языков подготовки сценариев ASP.NET и собственных сборок и настраивать различные параметры компиляции. Раздел <compilation> имеет несколько подразделов, но сначала рассмотрим свойства, устанавливаемые для элемента <compilation>. Ниже приведен синтаксис элемента <compilation>.

Таблица 4.5 содержит перечень свойств элемента <compilation>.

Таблица 4.5 включает большой объем новой информации, так что давайте опишем ее более подробно.

• Visual Basic explicit. По умолчанию Visual Basic позволяет использовать переменные, которые не были явно объявлены, но это считается плохим стилем. Опция Visual Basic Explicit гарантирует, что каждая используемая переменная объявлена с помощью операторов Dim, ReDim, Private или Public. Если вы используете Visual Basic .NET, я крайне рекомендую оставить эту опцию в настроечном файле включенной.
• Visual Basic strict. По умолчанию Visual Basic позволяет выполнять некоторые сомнительные операции программирования. При включении опции strict Visual Basic генерирует сообщение об ошибке, если выполняется одна из следующих процедур:
  • неявное преобразование типов, которое может привести к потере данных;
  • позднее связывание, состоящее в присвоении переменной, которая объявлена как объект.
   
• Пакетная компиляция. Страницы компилируются при первом доступе к ним, что приводит к небольшой задержке доступа к странице. Пакетная компиляция компилирует все еще не скомпилированные файлы из директории с файлом, к которому осуществляется доступ. Это означает, что доступ к первому файлу производится долго, но для последующих запросов таких задержек не будет.

Ниже приведен пример раздела <compilation>.

Имеется несколько подразделов, используемых в разделе <compilation>. Раздел <compilers> объявляет программы для компиляции страниц ASP.NET. Имеется набор компиляторов по умолчанию, включаемых в ASP.NET, но можно добавить компиляторы для обработки других языков, включая Delphi. Ниже приведен синтаксис раздела <compilers>.

Свойства раздела <compilers> перечислены в табл. 4.6.

Ниже показан элемент <compiler> для языка C#.

Перечислив три разных имени языка (c#; cs; csharp), при указании в свойстве language директивы @page языка C# можете использовать любое из этих трех имен. Элемент <compiler> позволяет добавлять новые языки программирования для написания программ для ASP.NET.

Добавление сборок к компиляции

Если вы когда-нибудь использовали один из компиляторов командной строки .NET, то знаете, что нужно включать сборки, которые требуется использовать при компиляции приложения. Раздел <assemblies> добавляет сборки, которые должны быть подключены при компиляции приложений ASP.NET. Аналогично разделу <appSettings>, этот раздел содержит коллекцию сборок, предназначенных для использования при компиляции приложений ASP.NET. Ниже приведен пример того, как добавлять сборку в раздел <assemblies>.

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

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

Он удаляет из коллекции все ранее добавленные в нее сборки.

Ключевые моменты <compilation>

Раздел компиляции включает важные параметры для оптимизации компиляции страниц ASP.NET. Ниже приведены ключевые моменты, связанные с работой в разделе <compilation>.

• Свойства strict и explicit элемента <compiler> позволяют установить в значение true опции Visual Basic strict и explicit для всех ваших файлов ASP.NET.
• Пакетная компиляция помогает сделать работу пользователя более "гладкой", позволяя скомпилировать еще не откомпилированные страницы ASP.NET при первом доступе к одной из них.
• Элемент <compiler> позволяет добавлять языки (даже COBOL.NET!) для программирования ASP.NET.
• Раздел <assemblies> позволяет добавлять сборки, подключаемые при компиляции страниц ASP.NET.

Работа с разделом <customErrors>

Раздел <customErrors> позволяет управлять сообщениями об ошибках, выводимыми пользователям. Это очень важный шаг при разработке дружественных к пользователю приложений. Имеется два типа ошибок, возвращаемых пользователям.

• Ошибки HTTP. Ошибки HTTP генерируются по нескольким причинам, включая отсутствие запрашиваемой страницы (404) или отсутствие прав доступа к запрашиваемой странице (403).
• Ошибки кода. Ошибки в вашем коде могут возникнуть из-за проблем с подключением к базе данных, неверным преобразованием типов данных или какой-либо недопустимой процедурой.

По умолчанию оба типа ошибок выдают пользователям отвратительные сообщения об ошибках. Это вопрос не только эстетический, но также и вопрос безопасности, так как сообщение об ошибке может включать информацию об имени пользователя или пароле. Элемент <customErrors> имеет два свойства: свойство mode и свойство defaultRedirect. Ниже приведен синтаксис элемента <customErrors>.

Свойство mode определяет, когда должны отображаться "дружественные" сообщения об ошибках, а когда – настоящие. Таблица 4.7 содержит список возможных значений свойства mode.

Когда приложение находится на стадии разработки, вы захотите видеть полные сообщения об ошибках, так что установите режим в значение Off или RemoteOnly. Когда начинается регулярная эксплуатация приложения, важно установить режим в значение On или RemoteOnly, так что пользователи не увидят подробных сообщений об ошибках.

При установке режима в значение RemoteOnly или Off пользователь видит стандартное сообщение об ошибке (большую отвратительную желтую страницу). Было бы здорово иметь возможность настраивать это стандартное сообщение и, возможно, включать в него логотип компании или информацию о технической поддержке. Свойство defaultRedirect используется для отображения стандартного сообщения об ошибке со страницы, отличной от страницы по умолчанию. Таким образом, вы можете создать для своего приложения собственное сообщение об ошибке, а затем указать URL этой страницы в свойстве defaultRedirect элемента <customErrors>, например:

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

Настройка сообщений об ошибках HTTP

Можно еще больше поработать над сообщением об ошибке, используя элемент <error> для перенаправления отдельных ошибок HTTP на собственные страницы ошибок. Элемент <error> позволяет указать конкретный код ошибки HTTP и страницу, на которую будут перенаправляться пользователи. Ниже приведен синтаксис элемента <error>.

Таблица 4.8 содержит перечень свойств элемента <error>.

Элемент <error> позволяет настроить сообщения об ошибках для каждого типа кодов HTTP. Например, можно создать различные сообщения об ошибках для кодов ошибок 404 и 403. Для кода ошибки 404 можно отображать сообщение, содержащее метод поиска страницы, которая не найдена. Для кода ошибки 403, скорее всего, следует предоставить пользователю информацию о регистрации в системе или способе получения информации о забытом пароле.

Дополнительная информация. С помощью метода Application_Error из файла global.asax можно добавить в приложения собственную обработку ошибок. Данный вопрос выходит за рамки книги, но это эффективный метод перехвата всех ошибок, возникающих в приложении, и отправки пользователю другой страницы или генерации сообщения e-mail об этой ошибке. Поищите информацию по этой процедуре по следующему URL: http://msdn.microsoft.com

Ключевые моменты <customErrors>

Раздел <customErrors> позволяет настраивать сообщения об ошибках, которые отправляются пользователям.

• Свойство mode элемента <customErrors> позволяет указать тип ошибок, отображаемым пользователям.
• Свойство defaultRedirect позволяет указать собственную страницу ошибки, на которую пользователи перенаправляются при ее возникновении.
• Элемент <error> позволяет широко настраивать сообщения об ошибках, указывая собственные страницы ошибок для конкретных кодов ошибок.

Работа с разделом <globalization>

ASP.NET имеет возможность обрабатывать запросы, ответы и файлы, используя для этого различные методы кодирования символов (кодировок). Раздел <globalization> позволяет указать тип кодировки и культуру для различных операций ASP.NET. Ниже приведен синтаксис раздела <globalization>.

Таблица 4.9 содержит перечень свойств раздела <globalization>.

Ниже показан пример раздела <globalization>.

Данная запись устанавливает кодировки запросов, ответов и файлов в значение UTF-8, а культуру – в значение English.

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

Ключевые моменты <globalization>

Глобализация играет важную роль в разработке приложений для содержащего множество культур интернет-сообщества.

• Можно задать тип кодировки запросов, ответов и файлов ASP.NET, используя свойства элемента <globalization>.
• Можно задать культуру веб-запросов, используя свойство culture элемента <globalization>.

Работа с разделом <httpHandlers>

Обработчики HTTP – это классы, которые обрабатывают HTTP-запросы для конкретного расширения файла, почти как расширения ISAPI. Обработчики HTTP существуют для aspx, .asmx, .rem и многих других расширений файлов ASP.NET по умолчанию. Раздел <httpHandlers> на основе действия HTTP, расширения файла и URL ресурса ставит в соответствие запросам HTTP корректный обработчик HTTP. Раздел <httpHandlers> – это еще один основанный на коллекции раздел, то есть в него можно добавлять и удалять элементы, очищать весь раздел полностью. Ниже приведен синтаксис добавления в раздел <httpHandlers> соответствий обработчиков HTTP.

Таблица 4.10 содержит перечень свойств раздела <httpHandlers>.

Ниже показан пример соответствия обработчика .aspx.

Когда с помощью одного из действий HTTP выполняется запрос к странице с расширением .aspx, страница обрабатывается обработчиком HTTP System.Web.UI.PageHandlerFactory. Удалить соответствие обработчика HTTP можно так:

Для сброса всех соответствий обработчиков, добавленных в предыдущие настроечные файлы, используется популярный элемент <clear />.

Теперь давайте рассмотрим, как создавать собственный обработчик HTTP для нового типа расширений.

Создание собственного обработчика HTTP

ASP.NET облегчает создание собственных обработчиков HTTP, которые могут обрабатывать запросы для собственных расширений файлов или путей файлов. В этом разделе вы научитесь создавать простой обработчик HTTP и поставите его в соответствие новому расширению .asbx. Имеется три типа обработчиков HTTP: синхронные, асинхронные и фабрики обработчиков. Синхронный обработчик обрабатывает весь запрос перед отправкой результатов пользователю. Асинхронный обработчик обрабатывает длинные запросы и позволяет отправлять информацию к пользователю на различных этапах обработки запроса. Фабрика обработчиков HTTP генерирует несколько обработчиков в зависимости от запроса. Файлы .aspx обрабатываются обработчиком из фабрики обработчиков HTTP, так что каждый запрос может быть передан в класс страницы для каждого файла. Класс страницы реализует интерфейс IHttpHandler и является обработчиком для каждой страницы.

Собственный обработчик HTTP – это класс .NET, который реализует либо интерфейс IHttpHandler, либо интерфейс IHttpAsyncHandler. Первым шагом при создании обработчика является объявление обработчика и реализации его интерфейса.

C#

VB.NET

При реализации интерфейса IHttpHandler следует включить метод ProcessRequest и свойство IsReusable. Если запрос HTTP связан с обработчиком HTTP, он вызывает метод ProcessRequest и передает в него текущий контекст HTTP. Затем можно использовать объект контекста HTTP либо для чтения из запроса, либо для записи ответа.

C#

VB.NET

Это очень простой метод ProcessRequest – он просто записывает через текущий контекст HTTP с помощью популярного метода Write короткое сообщение для пользователя. Когда пользователь пытается получить доступ к файлу .asbx, расположенному на сервере, вызывается этот обработчик, который отправляет пользователю простое сообщение. Прежде чем обработчик начнет работать, следует реализовать свойство IsReusable. Оно определяет, будет ли обработчик сохраняться в памяти для повторного использования или будет удаляться и воссоздаваться при последующем обращении к нему. Ниже приведен код, который требуется для реализации свойства IsReusable.

C#

VB.NET

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

Все запросы до передачи в расширение ISAPI aspnet.dll проходят через IIS. Если нужно, чтобы расширение файла интерпретировалось обработчиком, вы должны передать это расширение в расширение ISAPI aspnet.dll. Так следует зарегистрировать расширение .asbx в Internet Information Services.

1. Откройте инструмент администрирования IIS.
2. Перейдите в директорию или приложение, к которому нужно добавить это расширение.
3. Сделайте щелчок правой кнопкой мыши на этом приложении или директории, а затем выберите Properties (Свойства).
4. Появится экран как на рис. 4.1.

    

   
   
   Рис. 4.1.  Страница свойств приложения или виртуальной директории

    

    
5. Щелкните на кнопке Configuration (Настройка). Появится окно (рис. 4.2).

    

   
   
   Рис. 4.2.  Страница настройки соответствий приложения

    

    
6. Чтобы добавить в список соответствий новое расширение, щелкните на кнопке Add (Добавить). Появится окно (рис. 4.3).

    

   
   
   Рис. 4.3.  Страница настройки соответствий расширений

    

    
7. Установите путь к файлу .dll ASP.NET ISAPI, который находится в папке
   <drive>:\%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
8. В поле Extension (Расширение) введите .asbx и нажмите OK.

После передачи расширения в фильтр ASP.NET ISAPI нужно добавить обработчик в файл machine.config сервера.

Теперь все запросы с расширением .asbx будут обрабатываться собственным обработчиком. Чтобы дать вам лучшее представление обо всем процессе, приведу пошаговое описание короткой жизни HTTP-запроса.

1. Пользователь запрашивает веб-страницу с веб-сервера.
2. Запрос обрабатывается в IIS и направляется в расширение ISAPI ASP.NET.
3. ASP.NET получает запрос и пропускает его через несколько модулей HTTP. (Далее я их опишу.)
4. После того как запрос прошел через эти модули HTTP, он отправляется в собственный обработчик.
5. Вызывается метод ProcessRequest обработчика, и пользователю отправляется ответ.

Этот процесс происходит каждый раз, когда запрашиваемый ресурс соответствует одному из зарегистрированных обработчиков.

Безопасность на основе расширений файлов

ASP.NET использует большое количество расширений, и многие из них должны оставаться невидимыми для пользователей. Расширения типа .config, .cs или .vb должны быть защищены так, чтобы пользователи не могли получить доступ к этим файлам и прочитать код или настроечные параметры. Это делается с помощью направления расширений в расширение ASP.NET IIS ISAPI, а затем – в System.Web.HttpForbiddenHandler. Данный обработчик отменяет запрос и возвращает код ошибки HTTP 403 "Доступ запрещен". Это очень эффективный способ защиты таких расширений от любых запросов. Вы можете использовать его для защиты любых собственных расширений файлов, которые нужно скрыть от пользователей, сопоставив свое расширение с обработчиком System.Web.HttpForbiddenHandler.

Ключевые моменты <httpHandlers>

ASP.NET на самом деле дает в ваши руки огромную мощь, когда дело доходит до работы с запросами HTTP и создания собственных обработчиков. Вот список ключевых моментов, связанных с разделом <httpHandlers>.

• Раздел <httpHandlers> позволяет добавлять, удалять и полностью очищать список соответствий обработчиков.
• Обработчики HTTP – это классы, которые реализуют интерфейсы обработчиков HTTP, такие как IHttpHandler, IHttpAsyncHandler и IHttpHandlerFactory.
• Вы можете создать собственные обработчики HTTP для обработки собственных типов файлов.
• Вы можете защитить файлы от доступа пользователями, добавив запись соответствия обработчика для расширения файла, которая сопоставит его с обработчиком HTTP HttpForbiddenHandler.

Работа с разделом <httpModules>

Модули HTTP – это компоненты, расположенные между средой выполнения HTTP ASP.NET и обработчиками HTTP. ASP.NET использует их для выполнения некоторых процедур, включая аутентификацию, авторизацию и управление сессиями. С помощью модулей HTTP можно выполнять действия с запросами или ответами HTTP при их передаче от IIS в обработчик и обратно. Кроме всего прочего, модули могут шифровать, сжимать, аутентифицировать или записывать потоки запросов и ответов.

С помощью раздела <httpModules> можно настроить модули HTTP по умолчанию, а также зарегистрировать свои собственные модули HTTP.

Добавление модуля

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

Свойства элемента <add> перечислены в табл. 4.11.

Удалить модуль HTTP можно с помощью следующей записи.

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

Создание собственного модуля HTTP

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

Сначала создается базовая структура класса. Давайте посмотрим на нее.

C#

VB.NET

Это основа класса. Сначала класс реализует интерфейс IHttpModule, требующий методы Init и Dispose. Метод Init позволяет передать события HTTP в собственные обработчики событий. Метод Dispose позволяет удалять все соединения и ресурсы перед закрытием модуля. Возможно передать в метод Init несколько событий, каждое из которых возникает на различных стадиях процесса обработки запроса HTTP. В таблице 4.12 приведен перечень всех событий, которые можно связать с вашим HTTP-модулем.

Все эти события доступны для собственных модулей HTTP. Давайте посмотрим, как добавлять события в собственный модуль HTTP. Первым шагом является передача события в метод Init.

C#

VB.NET

Когда модуль инициализирован, событие EndRequest объекта Application передается в метод Application_EndRequest. Когда готов к отправке ответ, вызывается метод Application_EndRequest, модифицирующий ответ. Ниже приведен код, в котором данный метод модифицирует запрос.

C#

VB.NET

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

Теперь при обработке HTTP будет выполняться модуль копирайта, и в конец потока ответа будет добавлен текст об авторских правах.

Ключевые моменты <httpModules>

Раздел <httpModules> и собственные модули HTTP позволяют работать напрямую с потоком обработки HTTP.

• Раздел <httpModules> – это раздел, основанный на коллекции, в которую можно добавлять модули, удалять их из нее и полностью очищать эту коллекцию.
• Модули HTTP – это классы .NET, реализующие интерфейс IHttpModule. Данный интерфейс требует, чтобы класс включал методы Init и Dispose.
• Приложение HTTP предоставляет несколько событий, которые можно перехватывать в своих модулях. Каждое такое событие происходит на различных стадиях обработки HTTP и позволяет изменять на этих стадиях объекты запроса и ответа.

Работа с разделом <httpRuntime>

Раздел <httpRuntime> включает параметры, относящихся к среде выполнения HTTP ASP.NET. Параметры раздела включают установки максимального количества разрешенных запросов, размера запросов и времени хранения запросов. Ниже приведен синтаксис раздела <httpRuntime>.

Таблица 4.13 содержит перечень свойств раздела <httpRuntime>.

Ниже показан пример раздела <httpRuntime>.

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

Ключевые моменты <httpRuntime>

Раздел <httpRuntime> позволяет настраивать несколько параметров, связанных со средой выполнения HTTP ASP.NET.

• Свойство maxRequestLength управляет максимально возможным размером запроса в килобайтах, а также максимально допустимым размером закачиваемого файла, защищая сервер от атак на отказ в обслуживании.
• Свойство appRequestQueueLimit устанавливает количество запросов в очереди, перед тем как пользователи начнут получать ошибку 503 Server Too Busy.

Работа с разделом <identity>

Раздел настроек <identity> позволяет настраивать параметры заимствования прав для вашего приложения ASP.NET. Заимствование прав – это способность приложения действовать от имени пользователя при доступе к другим ресурсам. После аутентификации пользователя в IIS его опознавательный признак передается в ASP.NET, где он может использоваться для персонализации пользователя в других ресурсах. Если пользователь не аутентифицирован в IIS, в приложение ASP.NET передается признак отсутствия аутентификации.

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

Ниже показан синтаксис раздела <identity>.

Свойства раздела < identity > приведены в таблице 4.14.

Имеется два режима заимствования прав, которые можно использовать в приложении. Первый режим использует имя пользователя и пароль, переданные из IIS, а второй режим – имя пользователя и пароль, указанные в настроечном файле. Ниже приведен пример реализации первого режима заимствования прав.

Такой метод заимствования прав использует любые имя пользователя и пароль, переданные из IIS в среду выполнения ASP.NET. Вот пример реализации второго типа заимствования прав.

1. Когда приложение пытается получить доступ к ресурсу, который требует аутентификации, для аутентификации в этом ресурсе используются указанные здесь имя пользователя и пароль. Хранение имени пользователя и пароля в формате простого текста, как в данном случае, ведет к проблемам безопасности. Файл .config защищен от запросов со стороны пользователей и доступ к нему через IIS или любой другой метод, основанный на веб, запрещен. Однако доступ к этим файлам возможен, если у пользователя есть доступ к серверу или заимствованные права на доступ к этому файлу. Имеется возможность хранить имя пользователя и пароль в зашифрованном формате в реестре. Это делается следующим образом. В настроечном файле установите значения имени пользователя и пароля в:
   <identity impersonate="true" userName=
     "registry:HKLM\Software\AspNetLogin\ASPNET_SETREG,userName"
     password=
     "registry:HKLM\Software\AspNetLogin\ASPNET_SETREG,password" />

   Теперь настроечный файл будет считывать значения имени пользователя и пароля из реестра сервера.

    
2. Чтобы установить значения в реестре, используйте консольное приложение aspnet_setreg.exe. Это небольшое приложение, которое можно скачать с Microsoft Download Center или напрямую по ссылке http://download.microsoft.com/download/asp.net/Utility/1.0/WIN98MeXP/EN-US/Aspnet_setreg.exe
3. Распакуйте приложение, откройте командную строку и перейдите в директорию, в которую вы распаковали файлы.
4. Введите в командной строке следующее:
   aspnet_setreg –k:Software\AspNetLogin\Identity – u:UserName –p:Password

   Замените AspNetLogin\Identity на тот ключ, который вы хотите использовать. Этот ключ будет создан автоматически. Замените UserName и Password на корректные значения имени пользователя и пароля для вашего приложения.

    
5. Найдите ключ в реестре и проверьте, что процесс ASP.NET имеет доступ к этому значению, сделав щелчок правой кнопкой мыши на ключе и выбрав Permissions (Разрешения). Если имя пользователя ASP.NET не указано, добавьте его в список. Прежде чем права доступа вступят в силу, вы должны будете перезапустить процесс IIS.

После этого эти элементы в реестре будут зашифрованы и готовы для доступа из настроечных файлов.

Ключевые моменты <identity>

Раздел <identity> предоставляет параметры, которые включают и отключают заимствование прав для приложений ASP.NET.

• Первый режим заимствования прав читает имя пользователя и пароль из опознавательного признака, переданного из IIS, и использует его для доступа к ресурсам.
• Второй режим заимствования прав использует имя пользователя и пароль, указанные в настроечном файле.
• aspnet_setreg.exe позволяет шифровать и сохранять имя пользователя и пароль в реестре, а затем читать эти значения из настроечного файла.

Работа с разделом <machineKey>

В ASP.NET имеется несколько объектов и ресурсов, которые должны быть зашифрованы с целью обеспечения защиты. Раздел <machineKey> содержит ключи проверки и расшифровки, используемые для шифрования некоторых объектов ASP.NET, включая данные cookie форм аутентификации, данные viewstate и информацию о состоянии сессии, расположенной вне основного процесса. Ниже приведен синтаксис раздела <machineKey>.

Свойства раздела <machineKey> приведены в табл. 4.15.

Ниже показан пример раздела <machineKey>.

В этом примере оба ключа являются автогенерируемыми, и используется опция IsolateApps. Это набор параметров по умолчанию для файла machine.config.

Ключевые моменты <machineKey>

Раздел <machineKey> очень важен для внутренней работы ASP.NET, но он не относится к числу тех разделов, которые ежедневно используются при программировании. Ниже приведены ключевые моменты, относящиеся к этому разделу.

• validationKey и decryptionKey могут генерироваться автоматически или задаваться вручную.
• При работе с веб-формой следует указывать ключи вручную, так что они будут соответствовать друг другу по всей веб-ферме.

Работа с разделом <pages>

Раздел <pages> содержит настроечные параметры уровня страницы. Это те же самые параметры, которые можно установить на самой странице при помощи директивы @page, но они применяются ко всем страницам, на которые влияет данный настроечный файл. Ниже приведен синтаксис раздела <pages>.

Таблица 4.16 содержит перечень свойств раздела <pages>

Ниже показан пример раздела <pages>.

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

Включать или не включать состояние представлений?

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

Использовать или не использовать MAC?

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

Ключевые моменты <pages>

Раздел <pages> дает возможность установить свойства уровня @page для всех файлов, на которые влияют эти разделы настроек.

• EnableViewStatemac включает проверку MAC для всей информации состояния представления. Проверка гарантирует, что пользователи не могут вмешаться в данные состояния сессии.
• Решение включать или не включать состояние представления следует принимать для каждой страницы в отдельности, так как многие страницы вообще не требуют включения состояния представления.

Работа с разделом <processModel>

Раздел <processModel> в настроечном файле уникален, так как он полностью игнорируется при использовании Windows Server 2003. Плюс к этому, при использовании в Windows 2000 или Windows XP он читается непосредственно расширением ISAPI ASP.NET. По этой причине все изменения данного раздела требуют для вступления в силу перезапуска IIS. При работе с Windows Server 2003 вам не нужно беспокоиться об этом разделе, так как можно изменить его параметры в инструменте администрирования (см. лекцию 8). При использовании Windows 2000 или Windows XP раздел содержит большое количество параметров, относящихся к процессу ASP.NET. Ниже приведен синтаксис раздела <processModel>.

В разделе <processModel> имеется несколько свойств, которым требуется значение времени. Формат этих значений имеет вид Часы:Минуты:Секунды. Можно установить значение времени в Infinite (бесконечность). Таблица 4.17 содержит перечень свойств раздела <processModel>.

Ниже показан пример раздела <processModel>.

Раздел <processModel> по умолчанию не содержит всех значений; многие являются необязательными, и в случае их отсутствия используются значения по умолчанию.

Настройка сообщения Server Unavailable (Сервер не доступен)

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

1. С помощью свойства serverErrorMessageFile настройте раздел <processModel> так, чтобы он указывал на нужный файл. Этот файл содержит сообщение, которое следует отображать пользователям.
2. Создайте файл, который не обрабатывается процессом ASP.NET, и поместите его в то место, на которое указывает настроечный файл.

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

Запуск ASP.NET на контроллере домена

При запуске ASP.NET на контроллере домена имеются специфические проблемы. Если вы впервые устанавливаете ASP.NET на контроллере домена и пытаетесь получить доступ к приложению ASP.NET, то получите сообщение об ошибке Server Application Unavailable (Серверное приложение недоступно), так как по умолчанию ASP.NET выполняется под локальной учетной записью системы, отсутствующей на контроллере домена. Для настройки успешного выполнения ASP.NET на контроллере домена имеется две возможности.

• Настроить ASP.NET на работу с системной учетной записью, установив свойство username в значение System, что позволяет ASP.NET выполняться в системе с правами администратора. Этот, в общем-то, правильный подход не совсем хорош, так как дает ASP.NET полный контроль над контроллером домена.
• Настроить ASP.NET на использование для входа в контроллер домена ограниченной учетной записи домена. Этот подход лучше, так как уменьшает риск, связанный с безопасностью.

Ниже приведена процедура для корректного создания и настройки этой учетной записи.

1. Создайте на контроллере домена учетную запись и добавьте ее в группу пользователей.
2. Дайте этому пользователю право на вход в качестве пакетного задания.
3. Убедитесь, что этот пользователь имеет доступ ко всем требуемым директориям, включая все директории приложения ASP.NET.
4. При помощи свойств username и password раздела <processModel> установите имя пользователя и пароль учетной записи.

Разрешение проблем с взаимными блокировками ASP.NET

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

Ключевые моменты <processModel>

• Свойство serverErrorMessageFile позволяет настраивать сообщение "Server unavailable", отображаемое при перезапуске рабочего процесса или его недоступности по другой причине.
• При установке ASP.NET на контроллер домена требуется выполнить специальные шаги по настройке, прежде чем ASP.NET будет корректно работать.
• Поиск, разрешение и устранение взаимных блокировок ASP.NET является ключом к предоставлению наилучших условий для работы ваших пользователей.

Работа с разделом <securityPolicy>

Раздел <securityPolicy> – это соответствия имен уровней безопасности и файлов политики безопасности. Файлы политики безопасности содержат параметры безопасности, относящиеся к ASP.NET. Раздел <securityPolicy> содержит только один элемент, который называется <trustLevel>. Ниже приведен его синтаксис.

Свойства этого раздела приведены в табл. 4.18.

Ниже показан пример раздела <securityPolicy>.

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

Ключевые моменты <securityPolicy>

• Элемент <trustLevel> ставит соответствие между дружественным именем уровня доверия и файлом политики безопасности, содержащим параметры.
• Дружественные имена уровней доверия используются в разделе <trust> для указания разделов безопасности, под которыми должно выполняться приложение.

Работа с разделом <sessionState>

Раздел <sessionState> содержит параметры для настройки ASP.NET при работе с сессиями. Вы можете настроить сохранение сессий на локальной машине, на удаленном сервере состояний или на удаленном SQL-сервере. В разделе имеется несколько свойств, но вам потребуется только одно. Ниже приведен его синтаксис и значения.

Возможные значения свойства mode приведены в табл. 4.19.

Есть еще два свойства в этом разделе, которые применяются ко всем режимам состояний сессии. Ниже приведен их синтаксис.

Описание этих свойств приведены в табл. 4.20.

Ниже показан пример того, как следует использовать эти свойства.

Данные сессии вашего приложения будут храниться локально и не будут использовать cookies. Если сессия простаивает в течение 20 минут, сессия и все ее данные будут удалены.

Настройка сервера состояний

Сервер состояний позволяет настраивать один из серверов вашей веб-формы как специализированный сервер состояний сессий. Он отслеживает состояние и данные сессий для всех других серверов. Это очень важно, так как в противном случае вы не будете знать, какой сервер обрабатывает каждый запрос пользователей. Таким образом, вне зависимости от того, какой сервер обрабатывает запрос, информация о сессии сохранятся на специальном сервере, а затем берется с него. Сервер состояний по-прежнему обрабатывает веб-запросы, пока не окажется перегружен информацией о сессиях. Первым шагом в настройке приложения на использование сервера состояний является установка свойства mode в значение StateServer. Затем нужно настроить два дополнительных свойства в разделе <StateServer>. Ниже приведен их синтаксис.

В таблице 4.21 приведен перечень значений этих свойств.

Ниже показан пример раздела <sessionState>, настроенного на работу с сервером состояний.

Единственным дополнительным шагом является настройка сервера, который будет играть роль сервера состояний. Запустите службу сервера состояний – через оснастку Services MMC или при помощи следующего файла.

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

Настройка SQL-сервера состояний

Еще одним методом поддержки состояний для нескольких серверов или в веб-ферме является использование SQL-сервера. Первым шагом является настройка сервера в ферме на работу в качестве сервера состояний сессий. Для этого запустите сценарий InstallSQLState.sql, расположенный в директории <drive>:\%windir%\Microsoft.NET\Framework\ version. Он должен быть запущен на сервере, где работает SQL-сервер. Я создам базу данных с именем ASPState, включающую таблицы, хранимые процедуры и прочее, что требуется для запуска SQL-сервера состояний. Следующий шаг состоит в настройке приложения на использование SQL-сервера состояний. Ниже приведен синтаксис этой настройки.

В таблице 4.22 приведены значения данного свойства.

Ниже показан пример раздела, настроенного на работу с SQL-сервером состояний.

Данные состояния сессии для этого сервера будут храниться в SQL-сервере, расположенном по адресу 192.168.0.1.

Ключевые моменты <sessionState>

• Свойство mode позволяет настраивать приложения на хранение информации о сессиях локально, на сервере состояний или на SQL-сервере.
• Свойство cookieless позволяет настраивать приложение на запись информации о сессиях без использования cookies.
• Сервер состояний позволяет выделить один веб-сервер под сервер состояний сессий и использовать его другими веб-серверами. Это снимает часть нагрузки на другие веб-серверы и делает программирование для веб-ферм более простым.

Работа с разделом <trace>

Раздел <trace> позволяет настраивать разделы трассировки уровня машины, приложения или сайта. Трассировка – это одна из наиболее полезных функций, представленных в ASP.NET. Она позволяет увидеть большое количество информации о компиляции и отладке страницы. Ниже приведен синтаксис раздела <trace>.

Свойства раздела <trace> перечислены в табл. 4.23.

Ниже показан пример раздела <trace>.

Здесь выполнены следующие настройки: трассировка включена для приложений, вывод трассировки не добавляется в конец каждой страницы, но доступен через средство просмотра трассировки.

Ключевые моменты <trace>

• Вы можете указать, будет ли включена трассировка и как она будет себя вести.
• Свойство localOnly позволяет включать трассировку только для локальных запросов.
• Свойство pageOutput позволяет указать, будет ли трассировочная информация добавляться в конец каждой страницы, или она будет доступна только через средство просмотра трассировки.

Работа с разделом <trust>

Раздел <trust> позволяет настраивать уровень безопасности доступа к коду для машины или приложения. Ниже приведен синтаксис раздела <trust>.

Свойства раздела <trust> перечислены в табл. 4.24.

Ниже показан пример раздела <trust>.

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

Ключевые моменты <trust>

• Раздел <trust> позволяет указать уровень безопасности, на котором будет работать приложение.

Работа с разделом <webControls>

Этот маленький раздел содержит всего одно свойство, которое определяет расположение файла сценария проверки на стороне клиента. Ниже приведен синтаксис этого раздела.

Свойство clientScriptsLocation указывает на расположение файла сценария проверки на стороне клиента. Этот файл содержит сценарий, используемый для проверки элементов управления веб на стороне клиента. Ниже показан пример этого раздела.

Запись {0} будет заменена на имя пространства имен, а {1} – на номер версии .NET Framework. Для ASP.NET 1.1 и пространства имен System.Web результат преобразования выглядит так: aspnet_client/System.Web/1_1_4322/.

Ключевые моменты <webControls>

• Свойство clientScriptsLocation используется для указания пути расположения файлов сценариев проверки.

Работа с разделом <webServices>

Этот раздел включает параметры для настройки веб-служб XML, создаваемых ASP.NET. Он содержит несколько подразделов, которые работают как разделы, основанные на коллекциях.

Подраздел <protocols>

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

Свойство name используется для указания протокола, добавляемого в раздел <protocols>. Протоколы, которые можно добавить в этот раздел, приведены в табл. 4.25.

Ниже показан пример раздела <protocols>.

Здесь протоколы становятся доступными при доступе к веб-службам этого сервера. Вы также можете удалить протокол из коллекции, используя элемент <remove>, наприме:

Протокол HttpSoap теперь недоступен для веб-служб сервера. Можно также использовать элемент <clear /> для удаления всех протоколов, добавленных в коллекцию в предыдущих настроечных файлах.

Подраздел <serviceDescriptionFormatExtensionTypes>

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

Теперь расширение будет добавлено в коллекцию. Ниже показан синтаксис удаления типа из коллекции.

Теперь данный тип будет из коллекции удален. Вы также можете использовать элемент <clear /> для полного удаления всей информации из этого раздела.

Подразделы расширений SOAP

Имеется несколько подразделов расширений SOAP, которые позволяют добавлять на сервер расширения SOAP. Все эти разделы включают одни и те же элементы, показанные в табл. 4.26.

Ниже показан синтаксис добавления расширения в один из подразделов.

В таблице 4.27 приведен перечень свойств элемента <add>.

Ниже показан пример того, как использовать метод add.

Эти расширения будут запущены в следующем порядке.

1. SOAPExt
2. SOAPExt4
3. SOAPExt3
4. SOAPExt2

Так как все подразделы основаны на коллекциях, то можно использовать свойства <remove> и <clear />.

Раздел <wsdlHelpGenerator>

Это последний подраздел из раздела <webServices>. Он позволяет указать расположение файла справки по вашим веб-службам. Ниже приведен его синтаксис.

Свойство href должно указывать непосредственно на физическое расположение файла. Это расположение может быть абсолютным или относительно настроечного файла.

Ключевые моменты <webServices>

• Раздел <protocols> позволяет указать протоколы, которые могут быть использованы для доступа к веб-службам вашего сервера.
• Разделы расширений SOAP позволяют добавлять расширения и задавать их приоритет, используя группы и свойство priority.
• Подраздел <wsdlHelpGenerator> позволяет указать конкретный файл справки, относящейся к вашей веб-службе.