#php #text #customization
#php #текст #настройка
Вопрос:
Когда время разработки имеет значение, все, что другие могут помочь, — это цель. Мое PHP-приложение теперь параметризовано и настроено с помощью включаемого файла, который содержит массив в форме:
$config = array(
'company' => 'BMC' , // the visible company name
'aplicable_tax' => .21 , // the IVA tax
'context_arr' => array(
'case1' => 12, // the defalul value
'case2' => 13,
'case3' => 14
),
'EN_welcome_text' => 'hello', // do NOT translate on regionalization
// xx comparation matrix
'xx_maxref'=> 5,
'xx_range' => array( 0, 1, 2, 3, 4, 5, 6, 7, 8, 9),
'xx_comp' => array(
// V Other V > I >> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
/* 0 */ array( 0, 3, 5, 5, 5, 5, 5, 5, 5, 5),
/* 1 */ array(-3, 0, 3, 5, 5, 5, 5, 5, 5, 5),
/* 2 */ array(-5,-3, 0, 3, 5, 5, 5, 5, 5, 5),
/* 3 */ array(-5,-5,-3, 0, 3, 5, 5, 5, 5, 5),
/* 4 */ array(-5,-5,-5,-3, 0, 3, 5, 5, 5, 5),
/* 5 */ array(-5,-5,-5,-5,-3, 0, 3, 5, 5, 5),
/* 6 */ array(-5,-5,-5,-5,-5,-3, 0, 3, 5, 5),
/* 7 */ array(-5,-5,-5,-5,-5,-5,-3, 0, 3, 5),
/* 8 */ array(-5,-5,-5,-5,-5,-5,-5,-3, 0, 3),
/* 9 */ array(-5,-5,-5,-5,-5,-5,-5,-5,-3, 0),
),
// and so on
// and so on
// and so on
)
Но этот подход небезопасен, потому что любой разрешенный редактор может ввести PHP-код или ошибки.
Мои вопросы:
- Можете ли вы предложить простой и гибкий формат, который предоставил бы третьей стороне возможность параметризовать PHP-приложение?
- Существует ли скрипт преобразования из этого формата в PHP?
Комментарии:
1. Простая истина заключается в том, что если вы можете получить доступ к коду, вы можете взломать код.
2.
parse_ini_file()
не управлять 2D-массивамиjson
не управлять комментариямиXML
слишком многословно для редактора-пользователя: для любого отдельного значения нужны теги. Я напишу анализатор, если это необходимо (я уже написал несколько), поэтому, пожалуйста, предложите полезный формат «данных». (и если вам нужноregexes
или что-то подобное)
Ответ №1:
Ваша спецификация относительно защиты от взлома кода третьей стороной не может быть достигнута, если третья сторона имеет доступ к коду.
Все представленные на данный момент решения имеют ограничения, которые, на мой взгляд, нарушают более важные элементы вашей спецификации — гибкость и ремонтопригодность.
- Решение для базы данных может отделять параметры конфигурации от кода, но вы теряете гибкость формата (например, комментарии, сложные типы данных) и увеличиваете сложность, теряя удобство сопровождения. Кроме того, если разработчик имеет доступ к коду, он может просто перезаписать параметры конфигурации.
- Решение для кодирования — включает JSON, сериализацию и INI — те же проблемы, что и решение для базы данных. Ограничивается форматом кодировки. Добавлен уровень сложности. Разработчик с доступом к проекту все еще может перезаписать параметры конфигурации.
- Решение для базы данных кодирования содержит все те же проблемы.
Я повторяю — если вы можете получить доступ к коду, вы можете взломать код. Файл конфигурации PHP — это очень распространенный способ настройки вашего проекта. Если вы не доверяете это разработчикам, не предоставляйте им доступа. Не запутывайте код и не жертвуйте удобством сопровождения.
ОБНОВЛЕНИЕ, КАСАЮЩЕЕСЯ ФАЙЛА КОНФИГУРАЦИИ PHP
Если вы запрашиваете ответ о простейшем способе на PHP, то это должен быть INI-файл. Базовая конфигурация PHP берется из таких файлов. Этот формат предлагает весь необходимый вам синтаксис — комментарии, массивы и т.д. Его можно проанализировать с помощью встроенной функции — parse_ini_file(). Если вас беспокоит безопасность / доступ, как отмечалось выше, вы можете исключить его из проекта или сохранить в отдельном месте. И наоборот, если вы хотите разрешить кому-либо настраивать приложение без доступа к коду, они могут просто отредактировать INI-файл.
ОБНОВЛЕНИЕ, КАСАЮЩЕЕСЯ ND-массивов
Хотя это правда parse_ini_file()
, он не поддерживает многомерные массивы, вы можете комбинировать разделы с массивами для обеспечения более сложной конфигурации. Все, что выходит за рамки этого, на мой взгляд, опасно близко к плоскому файлу данных — не файлу конфигурации — и принадлежит другому месту (т. Е. базе данных).
Комментарии:
1. Я согласен со всем, что вы говорите, но каково решение? что вы имеете в виду, говоря «файл конфигурации PHP — это очень распространенный способ настройки вашего проекта» ? Я доверяю разработчикам, я единственный… jaja. Но я прошу моих минимальных усилий (и привлечения сторонних разработчиков), не теряя ясности и гибкости. в примере мне нужно решить эту проблему, чтобы иметь способ перевести приложение (все сообщения об ошибках там). Также приложение будет настроено (обдумывая значения) таким образом. Большое вам спасибо. Извините за мой английский.
2. Я обновил свой ответ предложенным мной решением для приложения на PHP .
3. Я обновил свой ответ комментариями, касающимися многомерных массивов.
Ответ №2:
Отличной альтернативой XML является YAML. Синтаксис YAML легкий и удобен для чтения / записи кем угодно. Еще один замечательный момент заключается в том, что YAML делает разницу между хэшами и массивами. Я рекомендую вам автономный компонент symfony:http://fabien.potencier.org/article/40/the-state-of-yaml-in-php
ваш файл будет выглядеть следующим образом :
company: BMC #the visible company name
aplicable_tax: 0.21 #the IVA tax
context_arr:
case1: 12 #the defalul value
case2: 13
case3: 14
EN_welcome_text: hello #do NOT translate on regionalization
#xx comparation matrix
xx_maxref: 5
xx_range: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
xx_comp:
# V Other V > I >> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
-[ 0, 3, 5, 5, 5, 5, 5, 5, 5, 5 ] # [ 0 ]
-[ -3, 0, 3, 5, 5, 5, 5, 5, 5, 5 ] # [ 1 ]
-[ -5,-3, 0, 3, 5, 5, 5, 5, 5, 5 ] # [ 2 ]
-[ -5,-5,-3, 0, 3, 5, 5, 5, 5, 5 ] # [ 3 ]
-[ -5,-5,-5,-3, 0, 3, 5, 5, 5, 5 ] # [ 4 ]
-[ -5,-5,-5,-5,-3, 0, 3, 5, 5, 5 ] # [ 5 ]
-[ -5,-5,-5,-5,-5,-3, 0, 3, 5, 5 ] # [ 6 ]
-[ -5,-5,-5,-5,-5,-5,-3, 0, 3, 5 ] # [ 7 ]
-[ -5,-5,-5,-5,-5,-5,-5,-3, 0, 3 ] # [ 8 ]
-[ -5,-5,-5,-5,-5,-5,-5,-5,-3, 0 ] # [ 9 ]
YAML обладает всеми преимуществами XML и даже больше.
Комментарии:
1. замечательно, цитирую по вашей ссылке: удобная для пользователя сериализация данных , которую я добавлю в заголовок. Спасибо
2. @Luis: Я собирался написать свой собственный ответ, но я больше не понимаю, почему — YAML — это то, что вы ищете.
Ответ №3:
Я считаю, что самым простым и гибким форматом должен быть JSON с использованием PHPS, встроенных в json_encode и json_decode. Тогда ваш конфигурационный массив выглядит следующим образом:
{
"company" : "BMC",
"aplicable_tax" : 0.21,
"context_arr" :
{
"case1" : 12,
"case2" : 13,
"case3" : 14
},
"EN_welcome_text" : "hello"
}
Преимущество в том, что вы также можете сохранить конфигурацию где-то еще (например, в базе данных) и не должны предоставлять пользователям прямой доступ к файловой системе.
Комментарии:
1.
serialize()
Не очень подходит для хранения переменной в db?2. Хм, я бы не стал использовать serialize для материалов, которые могут быть отредактированы пользователем. И да, без комментариев, вам нужно создать актуальную документацию для структуры объекта конфигурации — например, схему json json-schema.org .
3. Мне действительно нравится использовать JSON и для таких вещей, это чисто и просто. Единственным недостатком является то, что в случае, если что-то не так с синтаксисом JSON (пропущенная запятая, кавычки и т.д.),
json_decode()
функция не подскажет вам, в чем проблема. (Использование PHP-файлов еще хуже, поскольку пользователи обычно не понимают ошибок PHP, а вы не можете отловить синтаксические ошибки.)
Ответ №4:
Я использую таблицу DB, в которой есть ключ, значение и описание. Я запрашиваю значение конфигурации по его ключу, и описание отображается на странице настройки.
Один из способов защитить ваш конфигурационный файл — запросить ранее определенную константу, которую вы будете определять в своих скриптах.
Комментарии:
1. Вы можете сериализовать()… Но пока это не понадобилось.
Ответ №5:
Поместите эти данные в структуру XML — гарантированно без выполнения кода, многоуровневых вложений, любого типа структуры данных, комментариев. Все, что вам нужно, и подсветка синтаксиса IDE в качестве преимущества.
Для синтаксического анализа — SimpleXML (как вариант).
Ответ №6:
Вы всегда можете использовать файлы .ini для настройки. Они не только в значительной степени стандартны и очень удобочитаемы для человека, это упростит настройку вашего приложения. Эта функция может помочь вам: http://php.net/manual/en/function.parse-ini-file.php
Но вы должны помнить, что сказал Джейсон: «Простая истина заключается в том, что если вы можете получить доступ к коду, вы можете взломать код»
Ответ №7:
Учитывая, что .ini и .xml были отклонены, я бы рассмотрел это:
- Удалите $config = array(строка и); строки, сохранив только сопоставления ключ => значение и комментарии
-
Вместо того, чтобы включать конфигурационный файл, сделайте что-то похожее на:
eval(«$config = array(» file_get_contents(‘config.file’) «);»);
Вам следует немного проанализировать config.file
, чтобы обеспечить большую защиту от внедрения — на мой взгляд, символ без кавычек / без комментариев ;
является опасным символом, могут быть и другие. Большинство ошибок должны просто приводить к сбою eval.
Тем не менее, если вы не доверяете третьей стороне в том, что она не предоставит опасный включаемый файл, тогда вам нужно выбрать другой подход. Можете ли вы предоставить стороннему веб-интерфейсу, который отправляет вам файлы конфигурации? Комментарии / подсказки будут отображаться на экране в формате HTML, но у вас будет приятный и безопасный JSON для анализа.
Комментарии:
1. Все еще возможно внедрить PHP-код в config.file. Подумайте о SQL-инъекции.
2. Да, вот почему я сказал «Вы должны проанализировать»… Я иллюстрировал метод, а не писал полное решение для OP
3. Не волнуйтесь, мы все делаем это время от времени 🙂