Конфигурационные файлы. Создание конфига
Представляем вашему вниманию новый курс от команды The Codeby - "Тестирование Веб-Приложений на проникновение с нуля". Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое.
Cоздание файла App.Config c элементом connectionStrings
Продолжаем работать с приложением, созданным в предыдущей статье. Сегодня повысим гибкость, и переносимость нашего приложения, переместив строку подключения из кода программы в отдельный конфигурационный файл .
Создание и добавление файла App.Config
Чтобы создать конфигурационный файл необходимо выполнить несколько простых действий:
1. Перейдите в окно Solution Explorer
2. Нажмите правую кнопку мыши на имени текущего проекта
3. В появившемся контекстном меню выберите пункт Add, появиться дополнительное подменю, нажмите на пункт New Item.
4. Откроется диалоговое окно со списком шаблонов. Найдите шаблон с именем Application Configuration File, если требуется, измените, имя файла, после чего нажмите на кнопку Add.
В Solution Explorer появится добавленный файл App.Config .
Открываем добавленный файл, щелкнув по нему двойным кликом мыши в окне Solution Explorer.
Файл App.Config это обычный XML файл, внутри которого по умолчанию содержится строка декларации и один корневой элемент configuration. Сам же файл конфигурации, опять же по умолчанию, хранится в папке текущего проекта.
Если вы не знаете, что такое XML и как с ним работать, то прочитайте статью: , в которой вкратце изложены все основные моменты.
Создание и добавление элемента connectionStrings
Создадим новый элемент connectionStrings. Для этого сначала введите знак меньше ().
Внутри созданного элемента создадим ещё один элемент с именем add
Для данного элемента добавим несколько атрибутов. Чтобы добавить атрибут нажмите на клавишу пробел после слова add, появится меню авто подстановки.
Выберите атрибут name и нажмите на клавишу Enter
Внутри двойных кавычек укажите любое имя, например MysqlConStr.
Затем добавьте следующий атрибут connectionString
Внутри двойных кавычек нужно указать строку подключения, которая состоит из пары: ключ = значение.
Обязательные ключи:
Server указываем ip адрес или имя сервера, где лежит база данных MySQL. Предпочтительнее указывать ip адрес.
Database – имя базы данных;
Uid – пользователь;
Pwd – пароль;
Каждый пара отделяется точкой запятой, а для установки значения используется знак равно.
ConnectionString="Server=ip; DataBase=имяБД; Uid=логин; Pwd=пароль;"
Строка подключения может содержать множество других ключей, например:
Port по умолчанию MySQL сервер использует порт 3306 и его можно не указывать, но если же по какой-то причине номер порта был изменен, то его следует указать явно.
"Server=ip; DataBase=имяБД; Uid=логин; Pwd=пароль; Port=1034;"
SslMode если при работе с базой данных вы хотите использовать безопасное соединение с сервером, то укажите для данного параметра одно из следующих значений:
Preferred если сервер поддерживает SSL (криптографический протокол, который обеспечивает безопасность связи) то будет установлено безопасное соединение, если нет, то обычное.
Required все подключения будут только через протокол ssl. Если же на сервере нет поддержки ssl, то при обычном подключении вы получите отказ в подключении к серверу.
...; SslMode=Preferred;"
Все остальные ключи и их описание можно найти на официальном сайте MySQL.
После добавления строки подключения, добавим ещё один атрибут providerName, который будет хранить имя поставщика данных.
ProviderName = "MySql.Data.MySqlClient"
полное содержимое файла App.Config
Таким же образом можно указать любое количество строк подключения и поставщиков данных к разным базам данных: MSSQL, Oracle, Access, например:
Ещё одним преимуществом файлов конфигурации, является быстрое изменение данных, которое не требует перекомпиляции проекта, ведь достаточно всего лишь внести изменения в файл XML, который является отдельным файлом.
Получение данных из файла конфигурации
Конфигурационный файл создан и теперь осталось научиться читать данные из файла App.Config.
MySqlConnectionStringBuilder mysqlCSB; mysqlCSB = new MySqlConnectionStringBuilder(); mysqlCSB.Server = "127.0.0.1"; mysqlCSB.Database = "mytest"; mysqlCSB.UserID = "adminbd"; mysqlCSB.Password = "123";
Удалим весь блок кода, а так же строку
Con.ConnectionString = mysqlCSB.ConnectionString;
Затем напишем следующий код:
ConnectionStringSettings conString; conString = ConfigurationManager.ConnectionStrings["MySQLConStr"];
В квадратных скобках указываем значение атрибута name элемента add. В результате в объекте conString мы получаем все значения элементов и атрибутов файла App.Config.
И последнее, что осталось сделать, это передать в объект MySqlConnection созданную строку подключения.
Using (MySqlConnection con = new MySqlConnection(mysqlCSB.ConnectionString))
Using (MySqlConnection con = new MySqlConnection(conString.ConnectionString))
Либо можно сразу же не создавая объект ConnectionStringSettings передать в конструктор класса MySqlConnection конструкцию следующего вида:
СonfigurationManager.ConnectionStrings["MySQLConStr"].ConnectionString;
Задание профиля с помощью командной строки – метод далеко не всегда удобный. Даже при работе с самой командной строкой используется окружение для сохранения настроек, чтобы не задавать их всякий раз и для всякой команды. Что уж говорить о сложных системных службах, свойства которых должны сохраняться не от сеанса к сеансу, а постоянно (в том числе при перезагрузке системы). Вывод прост: профиль необходимо держать в файле, вроде того, что создается по команде "сохранить настройки".
Однако сам подход к хранению профиля в файле, при котором пользователь не может изменять этот файл напрямую, а пользуется "умными" конфигураторами, удобен только в случаях, когда настроек много, а цена ошибки невелика (например, при настройке внешнего вида рабочего стола). В общем случае довольно сложно задать поведение системы на основании описания (часто неявного) свойств того, что эта система должна получать в результате . Иными словами, из описания того, что должно получиться, далеко не всегда можно автоматически сделать вывод, как оно должно получаться.
Конфигурационный файл . Текстовый файл, содержащий настройки какой-нибудь части системы (утилиты, демона и т. п.). Как правило, считывается ею при запуске. Типичный для Linux способ организации профиля .
Одним словом, если есть конфигурационный файл , то должны быть и средства редактирования этого файла. Учитывая, что в Linux реализована высокоразвитая система хранения и переработки (как ручной, так и автоматической) данных в текстовом виде, изобретать какой-то новый формат – все равно что изобретать велосипед. Тем более, что именно текст, разделенный на строки и слова, лучше всего подходит тогда, когда есть четкое деление профиля на объекты управления и их свойства (например, настройки какого-нибудь демона и значения этих настроек). Вдобавок, именно со структурированными текстами отменно управляются текстовые редакторы Linux: Vi, Emacs и др:
Methody@localhost:~ $ cat .vimrc so $VIMRUNTIME/vimrc_example.vim " Some mappings map:wall!^M map! ^O:wall!^M " Tune up set shiftwidth=2 tabstop=8 history=200 viminfo="50 set showmode showmatch showcmd ruler modeline set autoindent ignorecase smartcase set nohlsearch noincsearch set dir=/var/tmp set wildmode=list:longest,full set wildmenu " Colouring syntax on colorscheme desert Пример 12.2. Настройки редактора vim
Вот как выглядит конфигурационный файл для Vim , написанный Мефодием на основе файла, взятого у Гуревича. Легко заметить, что файл состоит из команд режима командной строки Vi с комментариями (в отличие от большинства утилит Linux, в Vi комментарии начинаются на """). Символы " ^O " и " ^M " – это именно соответствующие управляющие символы (вставленные в текстовый файл с помощью " ^V ", см. лекцию 9). Такой конфигурационный файл легко понимать и изменять.
Как уже было замечено, набор переменных окружения составляет особенный профиль , к которому чувствительны все запускаемые программы – в этом его достоинство. Задаются переменные окружения обычно в командном сценарии, который тоже можно рассматривать как конфигурационный файл ). Например, во многих дистрибутивах используется конфигурационный файл .i18n для настройки языковых особенностей клавиатуры, языка вывода сообщений и т. п. 2Обозначение "i18n" происходит от слова " internationalization ", в котором 20 букв, т. е. "i", "n" и 18 букв между ними. :
Methody@localhost:~ $ cat .i18n LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R SYSFONTACM=koi8-r SYSFONT=UniCyr_8x16 DICTIONARY=russian MPAGE="-CKOI8-R" export DICTIONARY MPAGE Пример 12.3. Файл настройки языковых особенностей
Однако хранить настройки специфической программы (не нужные всем остальным) в окружении – не самое удачное решение: синтаксис, задающий переменную окружения , слишком прост (имя_переменной=значение ), а самих переменных становится слишком много, поэтому при просмотре трудно выделить, какая из них к какой группе настроек относится. Если пытаться упаковать все настройки в значение одной переменной, это значение окажется трудночитаемым, и все преимущество текстового формата сойдет на нет. Например, стандартный конфигурационный файл утилиты ls (точнее, только ее цветовых предпочтений) – /etc/DIR_COLORS (его можно подменить личным файлом ~/.dir_colors ) занимает около ста строк вместе с комментариями. Команда ls использует не этот файл, а создаваемую утилитой dircolors переменную LS_COLORS , значение которой – 600-символьная строка без всяких комментариев.
Если профиль слишком велик, держать его в одном конфигурационном файле – значит, доставлять пользователю сомнительное удовольствие разбирать этот файл целиком даже при необходимости внести минимальное изменение. Методов борьбы с неудобочитаемостью несколько. В частности, уже известный по лекции 10 механизм " .d ": файл разделяется на несколько независимых друг от друга файлов так, что редактировать приходится только один из файлов, а программа во время самонастройки считывает все.
Другой способ опирается на то, что изменения , которые пользователь вносит в профиль , как правило, существенно меньше объема всего профиля . Поэтому может быть выгодно хранить все настройки по умолчанию в каком-нибудь файле, менять который вообще не надо, а файл пользовательских настроек использовать как бы "поверх", изменяя профиль в соответствии с ними после того, как выставлен профиль по умолчанию. Дополнительное преимущество такого способа – в том, что пользователь всегда может подглядеть в "большой" файл, чтобы узнать, как оформляется та или иная настройка. Например, утилита updfstab, которая изменяет содержимое /etc/fstab при появлении или удалении съемного дискового носителя (например, лазерного диска), считывает данные из конфигурационного файла /etc/updfstab.conf . Сам этот файл состоит из единственной строки: include /etc/updfstab.conf.default , что приводит к чтению файла с настройками по умолчанию, где задан способ работы со многими съемными устройствами системы. Если администратору нужно как-то изменить поведение updfstab в отношении определенного устройства, он копирует соответствующую группу настроек из updfstab.conf.default в updfstab.conf после строчки include.. . и исправляет их. То, что эти группы настроек читаются дважды, не играет особой роли: чтение коротких файлов выполняется быстро.
Наконец, третий способ сделать конфигурационный файл удобочитаемым - секционирование профиля , когда все настройки разбиваются на группы, каждой группе дается собственное имя, и синтаксис конфигурационного файла проектируется так, чтобы границы групп хорошо различались при просмотре. В сущности, этот способ – предок схемы " .d ", где группе соответствует отдельный файл, однако нередки ситуации, когда разбивать на файлы неудобно (например, если группы не полностью независимы, поэтому может понадобиться редактировать их сразу несколько). Конфигурационный файл утилиты дозвона wvdial , например, секционируется по адресату (провайдеру) плюс отдельная секция "по умолчанию". Сами секции отделяются друг от друга заголовками, заключенными в квадратные скобки:
Root@localhost:~> cat .wvdialrc Modem = /dev/modem Baud = 115200 Init1 = ATZ Init2 = ATQ0 L0 M4 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Auto DNS = on Modem Type = Analog Modem Phone = 0123456 Username = fireman Password = Fire!Fire! TOnline = true Phone = 0246813 Username = cop-120 Password = gimmethegun Force Address=10.0.0.120 Пример 12.4. Секционированный конфигурационный файл
Утилита wvdial обладает высокоразвитым искусственным интеллектом: она самостоятельно догадывается, какой именно тип идентификации используется на сервере. Например, "с той стороны" может оказаться терминал Linux, которому требуется сначала ввести обыкновенное входное имя и пароль, затем надо получить командную строку, запустить на сервере сетевой демон pppd , и только после этого запустить pppd на собственной машине. Другой вариант: pppd на сервере уже запущен, а настройки "Username" и "Password" означают идентификационную информацию протокола CHAP , используемого pppd . Обо всем этом и о многом другом wvdial способна догадаться,так же как wvdialconf умел определять, какое же из устройств является модемом.
Однако на любой искусственный интеллект найдется непостижимая ему жизненная ситуация. На одном из серверов (секция "Dialer hotspace") тоже стоит программа с зачатками искусственного интеллекта, которая тоже пытается определить, каким способом хочет идентифицироваться позвонивший. Оттого эти два кудесника, созвонившись, все ждут, пока кто-нибудь не проявит себя... Помогает настройка TOnline , которая заставляет wvdial немедленно задействовать протокол ppp , на что сервер, подумавши "ах, ppp!", с облегчением запускает pppd . Остается вопрос: почему эта полезная настройка никак не отражена в документации (ее нашел в исходных текстах программы Гуревич)? Не потому ли, что пара wvdialconf-wvdial не по-Linux-овски стремится все делать за пользователя, а стало быть, пользовательская документация для разработчиков этой программы – не главное?
Идею чтения настроек по умолчанию можно развить. Оказывается, бывает удобно, когда описание настройки помещено не в руководство, а непосредственно в конфигурационный файл в виде комментариев. Тогда при изменении этой настройки пользователь сразу видит, что она собой представляет, при этом отпадает необходимость сначала находить строчку в файле, а потом искать ее же в руководстве. Такой распространенный способ оформления называется самодокументированием профиля . Например, файл /etc/man.conf , управляющий работой команды man , оформлен в самодокументированном стиле:
Methody@localhost:~ $ cat /etc/man.conf . . . # NOCACHE keeps man from creating cache pages ("cat pages") # (generally one enables/disable cat page creation by # creating/deleting the directory they would live in – man # never does mkdir) # # NOCACHE # The command "man -a xyzzy" will show all man pages for xyzzy. # When CMP is defined man will try to avoid showing the same # text twice. (But compressed pages compare unequal.) # CMP /usr/bin/cmp -s . . . Пример 12.5. Самодокументированный конфигурационный файл
Мефодий, может быть, и не понял бы сразу, зачем команде man использовать утилиту cmp, однако в поясняющем комментарии написано: когда нужно показать несколько руководств разом, они предварительно сравниваются, и показываются только несовпадающие.
Если пойти еще дальше, то можно создать несколько различных файлов с примерами настроек, чтобы пользователь мог взять один из них и довести до нужного ему состояния. Именно такую – демонстрационную – настройку Мефодий и включил в качестве настройки по умолчанию в свой .vimrc (в первой строке). Кстати, на самом деле профиль Vim весьма сложен, но большинство его настроек по умолчанию находятся в различных файлах дерева каталогов /usr/share/ vim – эдакая "схема .d/.d ", где файлы профиля , соответствующие подгруппам настроек, лежат в подкаталогах, соответствующих группам. Включение определенного настроечного файла может происходить неявно: например, строчка colorscheme desert из .vimrc приводит к чтению /usr/share/ vim /colors/desert. vim .
Конфигурационные файлы могут иметь довольно замысловатый синтаксис, если соответствуют сложным структурам данных (таковы, например, настройка irc-клиента irssi ) или содержать в себе дополнительные средства самодокументирования (например, файл настройки текстового www-броузера lynx не просто хорошо документирован, но и размечен теми же средствами, какие используются в самом броузере для представления HTML).
8 февраля 2009Конфигурационный файл - это просто XML-файл с соответствующим именем, со-
держащий набор необходимых тегов. Имя конфигурационного файла приложения
должно иметь следующий вид:
конфигурационный файл приложения myApplication.exe назван myApplication.
exe.coring. Конфигурационный файл должен располагаться в одном каталоге со
сборкой приложения, для настройки которого он предназначен.
Содержимое конфигурационных файлов определяется общей для этих файлов
схемой. Базовая структура конфигурационного файла выглядит так:
Обязателен только первый тэг, в котором указаны версия XML, используемая
кодировка и элемент
зательны и добавляются или удаляются по мере необходимости.
Чтобы создать конфигурационный файл для сборки, написанной на Visual Basic
.NET, выберите в меню File пункт Add New Item\Application Configuration File -
к проекту будет добавлен новый конфигурационный файл, в который можно вруч-
ную добавить необходимые элементы. При компиляции приложения файлу назна-
чается соответствующее имя.
При использовании Visual C# конфигурационный файл придется создавать и за-
полнять вручную при помощи текстового редактора (например, Блокнота). Гото-
вый конфигурационный файл следует сохранить с именем app.config и добавить к
проекту приложения.
Схема конфигурационного файла
Полностью обсудить схему конфигурационного файла в этом разделе на представ-
ляется возможным, но ее элементы верхнего уровня мы все же рассмотрим. Более
подробно об этом рассказано в документации по Visual Studio .NET. Элементы вер-
хнего уровня схемы конфигурационного файла описаны в таблице 9-1.
Таблица 9-1. Элементы верхнего уровня схемы конфигурационного файла
Элемент Что содержит
требуемую версию CLR
мусора
приложение использует криптографические технологии
> Создание конфигурационного файла для приложения на Visual Basic .NET
1. В меню Project выберите nyHKTAdd New Item - откроется одноименное окно.
2. В окне Add New Stem выберите шаблон Application Configuration File - к проек-
ту будет добавлен конфигурационный файл.
3. Внутри элемента < configuration > поместите элементы схемы для настройки не-
обходимых параметров. Более подробно о доступных элементах схемы - в доку-
ментации на Visual Studio .NET.
4. Сохраните созданный файл и скомпонуйте приложение.
> Создание конфигурационного файла для приложения на Visual C#
1. В меню Project выберите Add New Item.
2. В окне Add New Item выберите Text File - новый текстовый файл добавляется к
проекту и открывается в текстовом редакторе.
3. В окне Solution Explorer щелкните правой кнопкой новый текстовый файл и вы-
берите команду Rename, чтобы переименовать файл в App.config. В текстовом
редакторе добавьте к файлу следующий XML-код:
В окне Solution Explorer дважды щелкните файл App.config. Ответьте согласием
на вопрос о закрытии файла - среда разработки переключится в редактор с
XML-текстом файла App.config.
