Информация о настройках конфигурации для приложения ASP.NET хранится в одном или нескольких файлах конфигурации, основанных XML и названных Web.config. Стандартные настройки конфигурации для всех веб-приложений на веб-сервере расписаны в файле Web.config в каталоге $WINDOWS$\Microsoft.NET\Framework\version\CONFIG. Данные стандартные настройки могут быть добавлены либо переписаны для конкретного веб-приложения используя файл Web.config в корневом каталоге данного приложения. Более того, данные настройки конфигурации могут быть специализированы для веб-приложения от каталога к каталогу, при этом в подкаталоги приложения также добавляются файлы Web.config.
Файл Web.config описывает массив настроек конфигурации, включая: строки соединения, авторизацию, правила авторизации для ссылки (URL) и действия, которые будут предприняты в случае, если произойдет необработанное исключение. Многие настройки конфигурации отличаются для среды разработки и операционной среды. К примеру, когда вы разрабатываете приложение ASP.NET на вашем компьютере, то наверняка вы будете использовать базу данных, отличную от той, которая будет использована заказчиком в производстве. Следовательно, строки соединения с базой данных в Web.config должны быть обновлены при передаче приложения на использование.
Некоторые типы настроек конфигураций должны быть изменены при передаче приложения на использование, например, такие, как строки соединения с базой данных. Если данные изменения не будут сделаны, то приложение, скорее всего, не будет работать правильно при использовании. Не так уж и сложно помнить о том, что необходимо изменить данные типы настроек конфигурации. Но есть такие настройки, которые должны быть изменены при передаче приложения на использование, однако, если данные изменения не будут сделаны, приложение все равно будет работать при использовании. Можно забыть изменить данные настройки, и это может снизить производительность вашего приложения или сделать его более уязвимым к атакам злоумышленников. Данная статья детально рассматривает некоторые настройки конфигурации, относящиеся ко второй категории. Читайте далее, чтобы узнать больше об этом!
Разрешение пользовательских ошибок
Запрещенные операции в приложениях .NET (такие как неверное преобразование типов, попытка сослаться на пустое значение, попытка соединения с базой данных, которая недоступна и т.д.) вызывают исключительные ситуации (exception). Исключительные ситуации могут быть обработаны прямо в коде, используя блоки Try / Catch. Для приложений ASP.NET в случае если исключительная ситуация не будет обработана в коде, то она всплывет в ASP.NET runtime, что вызывает HttpUnhandledException. Как ASP.NET runtime отреагирует на HttpUnhandledException зависит от настроек конфигурации вашего приложения. Runtime выполнит одно из трех действий:
- Выведет общую страницу ошибок, которая просто сообщит о том, что произошла ошибка во время выполнения программы,
- Выведет страницу с детальной информацией об ошибке, включая вызванную исключительную ситуацию, в случае если код был скомпилирован с символами отладки, трассировкой стека и несколькими строками кода того места, где была вызвана исключительная ситуация.
- Специализированная страница с информацией об ошибке, которая является страницей ASP.NET и на которую будет перенаправлен пользователь.
Файл Web.config содержит элемент <customErrors> , который диктует выбор одного из трех указанных выше действий в случае возникновения необработанной ошибки. Атрибут mode<customErrors> может иметь одно из трех следующих значений: элемента
- On - всем пользователям отображается страница "Runtime Error" (Ошибка во время выполнения) или специализированная страница об ошибке в случае возникновения необработанной ошибки.
- Off - страница с описанием исключительной информации будет продемонстрирована всем пользователям в случае возникновения необработанной ошибки.
- remoteOnly - удаленные пользователи (пользователи, которые посещают страницу не через локальный хост (localhost)) увидят страницу "Runtime Error" или специализированную страницу об ошибке; страницу о деталях исключительной ситуации видят локальные посетители (в частности, это разработчики).
При возникновении необработанной ошибки в среде использования важно сделать так, чтобы пользователь не увидел страницу деталей исключительной ситуации, поскольку такая информация может вызвать риск, связанный с нарушением техники безопасности. К примеру, строка кода, где было вызвано исключение, может содержать в себе чувствительную информацию в исходном коде, такую, как нестандартный SQL-запрос или, что может быть еще хуже, строка соединения с базой данных. Даже если код, отображенный на странице деталей исключительной ситуации, не раскроет такие любопытные факты, простым отображением деталей исключения вы раскрываете некоторую информацию о том, как ваше приложение работает с посетителями. Это может раскрыть злоумышленникам дополнительную информацию о том, как составлено ваше приложение. Более того, страница с деталями исключения не выглядит настолько привлекательной для обычных пользователей. Вам стоит отобразить специализированную страницу об ошибке, где внешний вид будет более похож на дизайн вашего веб-сайта.
Использование Health Monitoring или ELMAH для записи и оповещения разработчиков о возникновении необработанного исключения |
|---|
|
Если вы заметили, что на вашем веб-приложении возникло необработанное исключение, то вам стоит установить свойство mode элемента <customErrors> файла Web.config в значение Off , тогда вы сможете увидеть детали ошибки и исправить ее. Недостатком такого подхода является то, что пока у вас отключена возможность пользовательских ошибок, все пользователи будут видеть ту же страницу с деталями исключения, которую видите вы. В идеале, приложение ASP.NET в использовании должно записывать все необработанные исключения в базу данных и отправлять по электронной почте разработчикам веб-сайта. Таким образом, вы будете сразу же оповещены в том случае, если во время использования приложения возникнет ошибка, при этом вы можете обратиться к журналу записей ошибок, вместо того, чтобы попытаться воспроизвести ошибку, при этом запретив пользовательские ошибки. Существует две известные библиотеки для записи необработанных ошибок: ELMAH и Health Monitoring. Вы можете найти более подробную информацию о данных библиотеках в интернете. |
Отключение трассировки выходных данных
Трассировка выходных данных позволяет разработчикам отображать информацию о запросе в нижней части страницы либо из специальной ссылки (URL) - Trace.axd. Трассировка может быть сконфигурирована для каждой страницы при помощи атрибута Trace в директиве @Page, либо может быть настроена для всего веб-приложения при помощи элемента <trace> в Web.config.
Включение трассировки в среде использования не приветствуется потому, что журнал трассировки отображает важную информацию включая куки (cookies), информацию, хранимую в состоянии сессии и любую диагностическую информацию, записанную в журнал трассировки. При включенной трассировке, злоумышленники могут посетить страницу Trace.axd и увидеть записи трассировки за последние несколько запросов к приложению.
Чтобы предотвратить отображение информации о трассировки во время использования веб-сайта вы можете либо отключить всю трассировку, либо настроить ее так, что она будет доступна только тем пользователям, которые посещают приложения через локальный хост (localhost). Элемент <trace> имеет два атрибута типа Boolean , которые указывают данные настройки: enabled и localOnly. Для получения более детальной информации об элементе вам стоит прочитать техническую документацию об элементе <trace> и про трассировку в ASP.NET.
Отключение поддержки режима отладки
При первом посещении ASP.NET-страницы либо при первом посещении после того, как она была модифицирована, декларативная разметка на странице будет автоматически скомпилирована в класс и затем будет "выполнена" ASP.NET runtime для того, чтобы сгенерировать содержимое, возвращаемое запросившему клиенту. Данное преобразование из декларативной разметки в исходный код и последующая компиляция кода гладко обрабатывается ASP.NET runtime в момент, когда был сделан запрос. Различные настройки относительно данного процесса компиляции могут быть установлены посредством элемента <compilation> в Web.config. Более того, исходный код в классах с фоновым кодом страниц ASP.NET может быть скомпилирован автоматически веб-сервером, либо разработчиком до передачи в использование. Если вы создаете свое собственное приложение при помощи проектной модели веб-сайта Visual Studio (Visual Studio Web Site Project model) a начнете с использования файлов кода (вместо использования скомпилированной сборки) , то тогда вы используете модель автоматической компиляции, и настройки элемента <compilation> также будут применены к автоматической компиляции классов с фоновым кодом.
Элемент <compilation> включает в себя атрибут debug , который указывает на то, что код должен быть скомпилирован в режиме отладки (debug) или в режиме эксплуатации (reatil). Код, скомпилированный в режиме отладки, включает дополнительные символы отладки и другую информацию, снижающую производительность, необходимую во время отладки. Для приложений в среде разработки, где вы будете активно заниматься отладкой, имеет смысл установить атрибут debug в значение true. Но при передаче вашего приложения в использование удостоверьтесь, что вы установили его обратно в false. Тем самым вы улучшите производительность вашего приложения, поскольку оно будет быстрее обрабатывать данные ресурсы и использовать меньше памяти при посещении страницы.
Более детально данная настройка конфигурации, а также почему она должна быть установлена в false, продемонстрирована в блоге Скотта Гутри (Scott Guthrie) - "Не используйте приложения ASP.NET с установленным атрибутом debug="true"". В ней перечислены четыре последствия установки атрибута debug в значение true:
- Компиляция страниц ASP.NET занимает больше времени (поскольку некоторая оптимизация незадействована)
- Код может быть выполнен медленнее (поскольку некоторые дополнительные пути отладки активированы)
- Гораздо больше памяти используется во приложении в время работы
- Скрипты и изображения, загруженные с обработчика WebResources.axd,не будут кэшированы
Цитата:
"Четвертый пункт наиболее важен, поскольку он означает, что все клиентские библиотеки javascript и статические изображения, которые будут использоваться посредством WebResources.axd будут заново загружены клиентами при каждом повторном запросе о просмотре страницы и не будут кэшированы локально в обозревателе. Это замедляет работу для таких вещей, как [ASP.NET AJAX], элементов управления, как TreeView/Menu/Validators, и любых других посреднических элементов управления или специализированного кода, который использует клиентские ресурсы. Обратите внимание, что причина того, что данные ресурсы не сохраняются, когда атрибут debug установлен в true, заключается в том, что разработчикам не приходится сбрасывать кэш обозревателя и перегружать его при каждом изменении обработчика ресурса (мы предполагаем, что когда у вас debug=true , вы активно разрабатываете свой сайт)."
Для получения оптимальной производительности вашего веб-сайта вам стоит удостовериться в том, что в файле Web.config во время использования приложения атрибут debug элемента <compilation> будет установлен в false.
Приемы конфигурации принудительного развертывания с использованием <deployment retail="true"/>
Если ваше приложение будет использовано на компьютере, над которым вы имеете контроль - к примеру веб-сервер во внутренней сети вашей компании или веб-сервер провайдера, то вы можете использовать элемент <deployment> в machine.config , чтобы заставить все приложения на веб-сервере принять все рекомендации, предоставленные выше (а именно - использование специализированной страницы ошибок, отключение трассировки выходных данных и не автоматически компилируемый код не должен быть скомпилирован в режиме отладки). Просто добавьте следующую разметку в файл machine.config в пределах элемента <system.web>:
<deployment retail="true" />
На заметку: Вы найдете файл machine.config в папке $WINDOWS$\Microsoft.NET\Framework\version\CONFIG.
И это все! Чтобы вернуть настройку в исходное значение, вы можете убрать данный элемент или установить атрибут retail в значение false (стандартное значение). Вам следует помнить о том, что элемент <deployment> может появиться только в файле machine.config , а не в Web.config, и применяется ко всем веб-сайтам на сервере.
Вывод
Существует множество настроек конфигурации относительно приложения ASP.NET и некоторые из них должны отличаться основываясь на том, находится ли приложение в среде разработки или же в использовании. Данная статья рассматривает три настройки конфигурации, которые могут не быть изменены при сдаче приложения в использование, но точно должны быть изменены, если вы хотите улучшить производительность вашего приложения, а также хотите быть уверены в мерах безопасности. Если у вас есть контроль над веб-сервером, то вы можете применить приемы конфигурации принудительного развертывания путем добавления <deployment retail="true" /> к файлу сервера machine.config.
Веселого программирования!
Scott Mitchell