Рекомендации по использованию конфигурации XML для PHP?

Question

Я планировал использовать XML-документ для хранения конфигурации для моего следующего проекта PHP в формате, аналогичном файлам ASP.NET Web.Config. Всего две проблемы:

1. Невозможно предоставить браузеру.
2. Должно быть жизнеспособным в общем хостинге.

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

<?xml version="1.0" ?> 
<!-- <?php if(!defined('FW_LOADED')){ exit; } ?> --> 
<configuration> 
.... 
</configuration> 

Это работает отлично, но я не чувствую себя это лучшее решение.

Кто-нибудь еще использовал XML для хранения конфигурации для проекта PHP? Какие хорошие альтернативные решения (вместо того, чтобы комментировать в начале файла, который выходит из сценария, если константа не определена)?

---

Update:

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

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

Лучшие решения до сих пор являются:

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

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

Answer 1

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

Answer 2

Либо поставьте их вне корня документа, либо если вы не можете или не сможете ограничить его доступ извне, используйте Apache mod_rewrite.Например:

RewriteEngine On 
RewriteRule ^config.xml [R=404,L] 

PHP имеет несколько библиотек для чтения/записи XML, поэтому проблем там нет. Если относительно простые (плоские) данные позволяют вместо этого использовать файлы INI. PHP имеет parse_ini_file() как встроенную функцию и что-либо на .Net будет читать файлы .ini.

Answer 3

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

Answer 4

Конфигурации XML медленные. Думаю, вам придется скомпилировать их на PHP. Или используйте PEAR_Config для упрощения задания. Что касается предотвращения доступа из браузера ... Простая директива Apache вместе с «Order allow, deny deny from all» будет делать. Проверьте документы apache.

Answer 5

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

Общий хостинг должен допускать оба этих сценария.

Answer 6

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

$conf['item1'] = 'value'; 
$conf['item2'] = 'value2'; 

и т.д ..

А затем файл называют файл, в котором определены все эти элементы $ конф и добавьте пути или URL-адрес сервера или что-то и сохранить все, что данные в файл с помощью var_export.

В конце вы получите «скомпилированный» файл, который вы можете легко вызвать.

Примечание: var_export получает содержимое массива, а не его имя или конец ';'

Answer 7

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

config.php:

return array(
'config1'=> 'config1value', 
'config2'=> 'config2value', 
); 

some_page.php:

$config= include('config.php'); 
if ($config['config1']) 
... 

Конфиг хранится в виде PHP-массива в PHP файл файла, поэтому он обрабатывается с помощью PHP двигателя и никогда не возвращался к т он браузер. (Вы также можете защитить конфигурационные файлы, сохранив их вне корневого веб-узла, установив правило mod_rewrite, чтобы предотвратить использование файлов конфигурации/каталогов и т. Д.)

Хранение информации конфигурации в файле XML добавляет накладные расходы на разбор XML-файла для каждого запроса. Хранилище данных с расширенными конфигурационными данными хорошо, но также дорого (очевидно, что база данных не будет хранить информацию о подключении к базе данных, так что вам по-прежнему потребуется решение для конфигурации для некоторой базовой информации). Конфигурационные данные, как правило, очень статичны (редко записываются/читаются каждый запрос), так что это зрелое кэширование через memcached или другие схемы кэширования.

Answer 8

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

PHP теперь имеет удобный SimpleXML http://php.net/manual/en/book.simplexml.php lib для управления данными XML. Хотя, я бы предпочел YAML http://www.yaml.org/ в качестве языка настроек, поскольку он не настолько подробен, как XML, и имеет приятные средства для компоновки файлов иерархической конфигурации, которые обычно необходимы, когда у вас есть несколько сред разработки, таких как dev, test, live. Существуют различные библиотеки PHP для работы с файлами YAML.

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

Относительно защиты доступа к файлу, который не обрабатывается интерпретатором PHP .xml или .yml, поскольку другие предложили сохранить его из рабочей папки или использовать правила перезаписи.

Answer 9

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

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

Никто не сказал ничего плохого в использовании оператора exit в верхней части XML-файла, поэтому, я думаю, я продолжу это делать, пока.