Как прагматично управлять файлами конфигурации управления версиями?

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

database_password=secret
foo=bar

становится

database_password=*
foo=bar

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

Пример:

Локальная версия:

database_password=own_secret
foo=bar

файл конфигурации в vcs:

database_password=*
foo=bar

Затем внезапно конфигурационный файл меняется:

database_password=*
foo=bar
baz=foo

И локальная версия стала бы для каждого разработчика:

database_password=own_secret
foo=bar
baz=foo

Это мое решение. Как я мог добиться такого поведения? Как вы храните свои файлы конфигурации? Есть ли способ это сделать, или надо что-нибудь взломать?


version-control svn configuration-files
person erenon    schedule 29.12.2009    source источник
comment
файлы конфигурации не должны содержать пароли в открытом виде ....   -  person Mitch Wheat    schedule 29.12.2009
comment
на самом деле, предпочтительнее никогда не иметь никаких паролей в файле конфигурации ... если только это не конфигурация сервера, и даже тогда ...   -  person Mitch Wheat    schedule 29.12.2009
comment
@Mitch: мое веб-приложение PHP (на основе ZF) считывает учетные данные БД из обычного текста. Где мне их хранить?   -  person erenon    schedule 29.12.2009
comment
вы имеете в виду программно, а не прагматически?   -  person    schedule 29.12.2009
comment
Я мог бы использовать ловушку предварительной фиксации svn, чтобы удалить свои пароли. И то, и другое работает только одним способом. Мне нужен какой-то пресинхронизатор или перехватчик перед обновлением.   -  person erenon    schedule 29.12.2009
comment
-1 для хранения паролей в виде открытого текста, что совершенно неуместно. См., Например, здесь   -  person Tobias Kienzler    schedule 09.10.2012
comment
@TobiasKienzler: Объясните, пожалуйста: каким образом я могу разблокировать свой пароль sql в файле конфигурации?   -  person erenon    schedule 10.10.2012
comment
@erenon Вы бы не стали, вы бы сравнили сохраненный хэш с хешем вашего введенного пароля sql. Реализация аутентификации, конечно, должна позаботиться об этом таким образом, чтобы хэш нельзя было ввести напрямую, т.е. он не стал паролем.   -  person Tobias Kienzler    schedule 10.10.2012
comment
@erenon См., например, здесь: Сохранение паролей - все сделано правильно! изменить На самом деле, есть соответствующий вопрос SO, надеюсь, он будет полезен: хранение паролей в SQL Server. Ваш вопрос в основном хороший, я был немного резок в формулировках и голосовании, приношу свои извинения за это   -  person Tobias Kienzler    schedule 11.10.2012
comment
Да, и Полное руководство по аутентификации веб-сайтов на основе форм   -  person Tobias Kienzler    schedule 11.10.2012
comment
@TobiasKienzler: Мне нужна аутентификация наоборот. (Не уверен, что вы это поняли.) Мое приложение должно предоставить пароль серверу SQL для создания соединения, а не аутентифицировать пользователя. (Я очень хорошо знаю концепцию хеширования, здесь это не сработает)   -  person erenon    schedule 11.10.2012
comment
@erenon m- / Извините, я ошибся. В зависимости от ваших требований к безопасности, вы все равно можете рассмотреть возможность шифрования ... (Голосование против отмены)   -  person Tobias Kienzler    schedule 11.10.2012

Ответы (9)


arrow_upward
27
arrow_downward

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

Также см. Мой ответ на аналогичный вопрос.

person Phil Miller    schedule 29.12.2009

arrow_upward
10
arrow_downward

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

У вас есть основная конфигурация, которая содержит общую конфигурацию плюс фиктивные имя пользователя / пароль (или вообще не учитывайте их). Затем каждый разработчик создает локальный файл override.config (или что-то еще) со своим конкретным именем пользователя и паролем. Основная конфигурация находится под контролем источника, а локальные изменения разработчика (или компьютера) - нет.

Я сделал это в .NET, но не в PHP, поэтому я не знаю, насколько это будет легко, боюсь.

person Paolo    schedule 29.12.2009
comment
Это кажется очень умным. Для этого, возможно, мне просто нужно создать подкласс парсера конфигурации моего фреймворка. - person erenon; 29.12.2009
comment
+1 Именно так мы обрабатываем файлы конфигурации почти во всех наших проектах с разными уровнями иерархии. - person ZoogieZork; 29.12.2009

arrow_upward
5
arrow_downward

Создайте локальный файл переопределений, содержащий информацию о пользователе в виде переменных PHP.

Например, создайте файл с именем local_overrides.php, который содержит следующее:

$local_password = 'qUzaEAFK13uK2KHy';

Затем в файле, содержащем ваш пароль БД, сделайте что-то вроде этого

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

Файл локальных переопределений никогда не должен быть виден системой управления версиями.

person Robert Groves    schedule 29.12.2009

arrow_upward
3
arrow_downward

У вас есть отдельный файл с ТОЛЬКО секретами, который не находится под контролем версий?

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

person James    schedule 29.12.2009
comment
Пароли используются программой PHP для подключения к базе данных. - person erenon; 29.12.2009

arrow_upward
2
arrow_downward

Как насчет ловушки перед фиксацией для очистки конфиденциальных полей? Это, конечно, предполагает, что вам удобно отправлять файл по сети.

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

person Andrew Coleson    schedule 29.12.2009
comment
В своем комментарии я только что придумал хуки перед фиксацией, но этот метод работает только одним способом. Каждый разработчик должен обновлять свои собственные поля пароля после каждого обновления и переопределения. - person erenon; 29.12.2009

arrow_upward
1
arrow_downward

Я привык делать из него текстовый файл со структурой файла конфигурации. И после этого я сделаю копию и изменю расширение, и пусть моя система контроля версий игнорирует этот файл (ы).

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

person Polichism    schedule 29.12.2009
comment
Такой подход нарушает принцип СУХОЙ. Во всяком случае, это могло сработать. - person erenon; 29.12.2009

arrow_upward
1
arrow_downward

Мой предпочтительный ответ на этот вопрос уже упоминался здесь: проверьте фиктивный файл, сгенерируйте «настоящий» файл, скопировав фиктивный файл во время выполнения, и игнорируйте «настоящий» файл в вашей VCS.

Я уже отвечал на аналогичный вопрос с полным примером того, как это сделать в Visual Studio:
как игнорировать файлы в печи / mercurial с помощью tortoise hg, которые являются частью репозитория

person Christian Specht    schedule 30.08.2012

arrow_upward
0
arrow_downward

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

Я не вижу другого способа сделать это. Если найдете другой подход, поделитесь.

person dfilkovi    schedule 29.12.2009
comment
Я думаю, что лучше оставить ваш конфигурационный файл в режиме игнорирования и после модификации изменить пароль на *, зафиксировать его, затем снова установить флаг игнорирования, а затем снова изменить * на пароль. - person erenon; 29.12.2009
comment
@erenon Это похоже на большие проблемы. Я ожидал, что разработчики в конечном итоге обойдут это или будут избегать регулярной фиксации (в любом случае фиксации файла конфигурации). Хотя возможно, вы могли бы написать скрипт для всей процедуры. - person Matthew; 29.03.2010

arrow_upward
0
arrow_downward

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

person Noufal Ibrahim    schedule 29.12.2009