Меню Закрыть

Asp net web config

Содержание

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

  • Для начала давайте познакомимся со специальным классом WebConfigurationManager. Давайте перейдем к определению этого класса, и посмотрим из чего он состоит. Этот класс находится в пространстве имен System.Web.Configuration. Мы видим определенный набор свойств и методов, часть из которых перегружена. Класс довольно простой.

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

    AppSettings – это свойство возвращает стандартную NameValueCollection коллекцию, которая представляет собой набор простых настроек приложения. Обращаясь по ключу или по индексу, можно получить значение определенного элемента в секции appSettings в файле Web.config.

    ConnectionStrings – это свойство возвращает коллекцию объектов класса ConnectionStringSettings. Данный класс описывает конкретную строку подключения к внешнему источнику данных, например, к базе данных.

    GetWebApplicationSection(section) – этот метод возвращает объект, с помощью которого можно получить информацию об определенной секции в конфигурационном файле, и уже как-то работать с ее конкретными атрибутами.

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

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

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

    Теперь посредством класса WebConfigurationManager мы можем обратиться к секции appSettings и прочитать новые настройки:

    Таким образом, секция appSettings в файле Web.config – это идеальное место для объявления простых настроек в нашем приложении, которые можно описать правилом «ключзначение».

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

    Давайте попробуем создать более сложную структуру, подобную группе system.web. То есть мы объявим новую группу, в которую будут вложены отдельные элементы с нужными атрибутами:

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

    То есть, мы наследуемся от класса ConfigurationSection, а внутри нашего класса ассоциируем свойства с соответствующими атрибутами в секции.

    Далее нам нужно подобным образом описать объявленную нами группу userCustomSettings, в которую вложен элемент defaultValues. Опять создаем класс обработчик, в этот раз для группы:

    После этого нужно зарегистрировать объявленную группу и секцию в файле Web.config в разделе configSections:

    Теперь все подготовительные действия закончены, и мы можем прочитать нашу конфигурацию:

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

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

    Теперь, если мы удалим из конфигурации атрибут timeZoneShift, то будет использовано его значение по умолчанию — 5. В то же время, если мы удалим атрибут city (который теперь стал обязательным), то увидим ошибку конфигурации, и наше приложение не сможет стартануть.

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

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

    CallbackValidator — используется, чтобы реализовать пользовательскую валидацию (см.ниже).

    StringValidator — используется, чтобы реализовать простую валидацию над строковыми значениями. Например, ограничить длину строки.

    IntegerValidator — используется, чтобы реализовать валидацию над значениями типа int. Например, ограничить число некоторым диапазоном.

    LongValidator — используется для валидации значений типа long.

    TimeSpanValidator — используется для валидации TimeSpan значений. Например, также можно ограничить диапазон значений.

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

    Одним из наиболее интересных атрибутов является атрибут CallbackValidator. Он позволяет нам произвести проверку значения по нашим собственным условиям. Мы объявляем метод, в котором будет проводиться проверка, передаем название этого метода в валидатор, и в момент загрузки конфигурации приложения этот метод будет вызван для проверки значения в конфигурации.

    Читайте также:  Приложение для репоста в инстаграме на андроид

    Давайте напишем метод, в котором сделаем проверку, что если в представленном email нет слова admin, то тогда выбрасывать исключение, что представленный емаил нам не подходит:

    Обратите внимание на важный момент. Особенность работы валидационных атрибутов такова, что валидаторы вызываются дважды за проверку. Первый раз в валидатор передается значение по умолчанию для данного типа (пустая строка для типа string, 0 для типа int и т.д.). Далее происходит второй вызов валидатора, и уже передается значение из файла Web.config. Именно поэтому мы сперва делаем проверку на пустую строку в конструкции if. Если не обработать двойной вызов валидатора должным образом, то наша проверка будет завершаться неудачно.

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

    Для того, чтобы работать со строками подключения, указанными в конфигурации, мы обращаемся к классу WebConfigurationManager, к свойству ConnectionStrings. Это свойство возвращает объект класса ConnectionStringSettingsCollection, который содержит коллекцию всех объявленных строк подключения:

    Как видно, работать со строками подключения очень просто и удобно. Для этого в классе WebConfigurationManager определено специальное свойство.

    Нам осталось рассмотреть вопрос переопределения конфигурации для какой-то части приложения. Это можно сделать двумя способами:

    • через элемент location в файле Web.config
    • через вложенный файл Web.config
    • Элемент location позволяет нам определить отдельные секции в конфигурационном файле, которые будут задействованы при обращении по определенному URL. Например, добавим особые правила для действия Index в контроллере Home:

      Теперь при обращении по этому URL объявленная нами конфигурация будет переопределена новыми значениями. Обратите внимание, что другие элементы секции appSettings были унаследованы от родительской конфигурации в файле Web.config.

      Однако использовать данный подход следует с осторожностью, либо не использовать вовсе. Все дело в системе маршрутизации нашего приложения. Если у вас определены какие-то другие маршруты помимо стандартного, то явное указание URL-адреса в элементе location может стать проблемой. Обратите на этом внимание.

      Также мы можем создать дополнительный файл Web.config в поддиректории нашего приложения. Например, создадим конфигурационный файл в папке Views/Home:

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

      Также хочу заметить, что мы можем не только получать информацию о текущих настройках приложения, но и изменять настройки приложения в runtime. Например:

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

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

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

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

      Ниже показано содержимое простейшего файла web.config, который получается при создании пустого веб-сайта ASP.NET в Visual Studio:

      Как и все XML-документы, содержимое файла web.config чувствительно к регистру символов. Каждый параметр использует стиль Camel и начинается с прописной буквы. Это означает, что записывать вместо не допускается.

      Конфигурационный файл для приложений ASP.NET 3.5 имеет более сложную структуру из-за способа, которым ASP.NET 3.5 была выпущена. По сути, ASP.NET 3.5 представляет собой комбинацию, которая состоит из базовой модели ASP.NET 2.0, со средой CLR 2.0, и набора расширений. Как результат, каждое приложение использует файл web.config для подключения новых средств. Однако в ASP.NET 4 такой подход не применяется, и приложения ASP.NET имеют более простое и понятное содержимое. Дополнительные параметры настройки были перемещены в файл machine.config и корневой файл web.config, где им самое место.

      Наследование конфигурации

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

      Например, рассмотрим веб-запрос http://localhost/A/B/C/MyPage.aspx, где А представляет корневой каталог веб-приложения. Этот запрос подразумевает использование параметров на множестве уровней:

      Сначала применяются используемые по умолчанию параметры из файла machine.config.

      Читайте также:  1С word двоичные данные

      Далее применяются параметры из файла web.config, находящегося в корневом каталоге компьютера. Этот файл web.config хранится в том же каталоге Config, что и файл machine.config.

      Если в корневом каталоге приложения А имеется файл web.config, тогда следующими применяются параметры, указанные в нем.

      Если в подкаталоге В имеется файл web.config, тогда следующими применяются параметры, указанные в этом файле.

      Если в подкаталоге С есть файл web.config, тогда напоследок применяются параметры из него.

      этой последовательности, показанной на рисунке, важно обратить внимание, что подкаталогов может быть сколько угодно, но параметры, применяемые в шагах 1 и 2, имеют особое значение. Причина в том, что некоторые параметры (такие как учетная запись Windows, используемая для выполнения кода) могут применяться только на уровне machine.config, а некоторые (вроде типа аутентификации, используемого веб-приложением) — только на уровне корневого каталога приложения.

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

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

      Если вы разрабатываете веб-проект (а не беспроектный веб-сайт), в состав этого проекта будут также включены файлы web.Debug.config и web.Release.config. Эти файлы предназначены для переключения между параметрами, используемыми при тестировании веб-приложения, и параметрами, которые необходимы во время его развертывания в производственной среде. Однако они не дают никакого эффекта при запуске приложения в Visual Studio, поскольку в этом случае они полностью игнорируются.

      Использование элементов

      Элемент является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе . Например, в следующем файле web.config элемент применяется для создания двух групп параметров настройки — для текущего каталога и для подкаталога Secure:

      Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.

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

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

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

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

      При блокировании параметров настройки в файле machine.config возможны два варианта: первый — заблокировать параметры сразу для всех приложений, опустив в дескрипторе атрибут path, а второй — заблокировать параметры только для конкретного приложения, указав в атрибуте path имя соответствующего веб-приложения.

      Элемент

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

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

      Некоторые базовые разделы конфигурации

      Элемент Описание
      authentication Этот элемент конфигурирует систему аутентификации — другими словами, он определяет, как будут проверяться идентификационные данные клиента, когда он запрашивает страницу
      authorization Этот элемент управляет тем, каким клиентам должен предоставляться доступ к ресурсам, находящимся внутри веб-приложения или текущего каталога
      compilation Этот элемент идентифицирует версию .NET, на которую ориентировано веб-приложение (посредством атрибута targetFramework) и указывает, должны ли генерироваться символы отладки в файлах .pdb (через атрибут debug), чтобы можно было отлаживать приложение с помощью инструмента, подобного Visual Studio. Этот элемент также может содержать элемент , в котором перечисляются дополнительные сборки, необходимые для веб-приложения. Эти сборки затем делаются доступными для кода (при условии, что их удается обнаружить в каталоге Bin или в GAC)
      customErrors Этот элемент позволяет указывать специфичные URL-адреса, которые должны использоваться для переадресации в случае возникновения определенных (или стандартных) ошибок. Например, он может использоваться для перенаправления пользователя с неприглядной страницы ошибки 404 (page not found — страница не найдена) на более дружественную по отношению к пользователю страницу. Хотя этот параметр работает с встроенным тестовым веб-сервером Visual Studio, в IIS 7.x он заменен разделом
      membership Этот элемент позволяет конфигурировать систему членства ASP.NET, которая управляет информацией пользовательских учетных записей и предоставляет высокоуровневый API-интерфейс для решения связанных с безопасностью задач, таких как вход пользователя в систему и переустановка пароля
      pages Этот элемент позволяет определять параметры, которые должны использоваться для страниц по умолчанию (большинство из которых может быть переопределено с помощью директивы Page)
      profile Этот элемент позволяет конфигурировать систему профилей ASP.NET, которая автоматически сохраняет и извлекает информацию по конкретному пользователю (обычно параметры профиля). Как правило, данные профилей сериализуются в базу данных
      roleManager Этот элемент позволяет конфигурировать систему безопасности на основе ролей ASP.NET, которая предоставляет способ сохранения информации о ролях и высокоуровневый API-интерфейс для авторизации на основе ролей
      sessionState Этот элемент конфигурирует различные опции, касающиеся обслуживания состояния сеанса для приложения, такие как, должно ли оно вообще поддерживаться, и если да, то где (в SQL, отдельная служба Windows и т.д.)
      trace Этот элемент конфигурирует трассировку, т.е. средство ASP.NET, которое позволяет отображать диагностическую информацию на странице (или собирать ее для отдельного просмотра)
      Читайте также:  Gigabyte radeon hd 4850

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

      Раздел

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

      Раздел

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

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

      После добавления такой информации .NET позволяет чрезвычайно легко извлекать ее в коде веб-страниц. Все, что понадобится — это просто использовать класс WebConfigurationSettings, который находится в пространстве имен System.Web.Configuration. Этот класс предоставляет статическое свойство AppSettings, в котором содержится динамически генерируемая коллекция всех доступных в текущем каталоге параметров приложения.

      Например, если класс страницы ASP.NET, ссылающийся на коллекцию AppSettings, находится в http://localhost/MyApp/MyDirectory/MySubdirectory, то в коллекции AppSettings, вероятно, будут содержаться параметры настройки из трех разных файлов web.config. Коллекция AppSettings делает такую иерархию параметров бесшовной для страницы, которая ее использует.

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

      Далее останется просто извлечь требуемое значение по имени:

      Ниже показана тестовая веб-страница в действии:

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

      I’m trying to configure the IIS Authentication settings from my MVC5 project in the Web.config file.

      Here’s what I have. I want Windows Authentication enabled and Anonymous Authentication disabled.

      But after publishing my package in IIS, the settings are this.

      What do I need to do to also set the Anonymous Authentication to Disabled in the Web.config? Isn’t that what is supposed to be doing?

      2 Answers 2

      Here we go step by step:

      Open Internet Information Services (IIS) Manager:

      • If you are using Windows Server 2012 or Windows Server 2012 R2:
      • On the taskbar, click Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.
      • If you are using Windows 8 or Windows 8.1:
      • Hold down the Windows key, press the letter X, and then click Control Panel. Click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.
      • If you are using Windows Server 2008 or Windows Server 2008 R2:

      On the taskbar, click Start, point to Administrative Tools, and then click

      Internet Information Services (IIS) Manager.

      If you are using Windows Vista or Windows 7:

      Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

      1. In the Connections pane, expand the server name, expand Sites, and go to the level in the hierarchy pane that you want to configure, and then click the Web site or Web application.
      2. Scroll to the Security section in the Home pane, and then double-click Authentication. 4.In the Authentication pane, select Anonymous Authentication, and then click Disable in the Actions pane.

      Or you can disable by config file:

      Deny Anonymous user to access entire website:

      Рекомендуем к прочтению

      Добавить комментарий

      Ваш адрес email не будет опубликован.