Я видел людей (которые обычно пишут хороший код), которые напрямую изменяют $_POST
массив следующим кодом:
// Add some value that wasn't actually posted
$_POST['last_activity'] = time();
// Alter an existing post value
$_POST['name'] = trim($_POST['name']);
// Our pretend function
// Pass the entire $_POST array as data to work with in the function
// The function update_record() will read only the values we actually need
update_record($_POST);
// ...That sure was easier than creating a new array
// with only the $_POST values we actually need.
Имеет смысл, что update_record()
не следует обращаться к $ _POST напрямую, чтобы мы могли передать ему, например, другие массивы данных, но, конечно, это ленивый, плохой дизайн или, возможно, просто неправильный? Однако мы по-прежнему передаем действительный массив update_record()
, так зачем создавать новый?
Это не суть вопроса, просто пример использования. Тем не менее, я слышал, что многие люди говорят, что это не должно быть сделано с $_REQUEST
данными, и это плохая практика. Но почему? Выглядит достаточно безобидно.
Примеры:
Установка значения по умолчанию
$_GET
(или публикации), которое на самом деле не существуетДобавление
$_POST
значений, которые фактически не были опубликованы после отправки формыНепосредственная очистка или фильтрация
$_GET
значений массива или ключей в самом начале скрипта (резервная очистка ... почему бы и нет?)Установка
$_POST
значения вручную перед отправкой формы для заполнения ввода значением по умолчанию (когда вход считывает$_POST
значение по умолчанию; я сделал это)Составляя свои собственные
$_SERVER
ценности? Конечно, эй, почему бы и нет?Как насчет других, как
$_COOKIE
и$_SESSION
? Конечно, мы должны изменить те прямо, верно? Тогда почему не остальные?
Должна ли прямая модификация суперглобалистов никогда не проводиться, или это нормально в некоторых случаях?
Ответы:
Учитывая , что PHP уже эти настройки суперглобального, я не думаю , что это зло , чтобы изменить их. В некоторых случаях это может быть лучшим способом решения проблем ... особенно когда речь идет о стороннем коде, который вы не можете легко изменить. (Они могут использовать
$_GET
напрямую или предположить, что какой-то ключ существует в$_SERVER
и т. Д.)Однако, вообще говоря, я думаю, что это плохая практика, когда вы пишете свой собственный код. Изменение
$_REQUEST
данных с помощью некоторого скрытого фильтра, который автоматически запускается на каждой странице, может вызвать побочные эффекты. (См. Все проблемы, которые «магические цитаты» вызвали для доказательства.)Так что, если вы не собираетесь этого делать (автоматически фильтруете суперглобалы), то следующее не даст вам никаких преимуществ:
когда вы можете легко сделать:
Я думаю , что это гораздо более ясно , чтобы сделать общесистемное различие , которое
$_POST
и$_GET
будет всегда нефильтрованными, ненадежные данные, и они не должны никогда быть использован как есть.Копируя отфильтрованное значение в другую переменную, вы заявляете, что «я понимаю, что делаю ... Я отфильтровал этот ввод, и его можно безопасно использовать».
источник
$_POST
, и санировать по мере продвижения. Что касается других людей, которые делают это ... ну, многие пишут очень плохой PHP-код, но это также не оправдывает вас. :)Я бы вообще предложил, чтобы вы не изменяли предопределенные суперглобальные переменные, чтобы было ясно, что такое очищенные данные, а что необработанные / ненадежные данные.
Другие могут предположить, что если вы очистите суперглобальные переменные в начале цикла запроса, вам не нужно беспокоиться о них в другом месте.
Я всегда сопоставляю их, когда они вам нужны:
или похожие.
С точки зрения других переменных , это хорошая практика , чтобы не писать ни одному из
$_GET
,$_POST
,$_REQUEST
,$_SERVER
или$_COOKIE
.$_SESSION
однако отличается, потому что вы часто хотите записать данные в сеанс, которые затем сохраняются по различным запросам в сеансе.источник
setcookie
существует, но мы получаем куки через$_COOKIE
? Кроме того, поскольку$_COOKIE
он устанавливается только при запуске текущего сеанса и никогда не обновляется, требуется, чтобы вы изменили / установили файлы cookie в обеих областях, чтобы более поздние области кода имели актуальную информацию.Вам следует избегать этого. Может быть, когда-нибудь вы забудете что-то очистить, тогда вы сможете извлечь опасные данные. Если вы копируете данные в новую структуру во время очистки
$_POST
слишкомДополнительные другие скрипты могут предполагать, что массив не тронут и может реагировать любопытно.
источник
Мне никогда не нравилась идея модификации superglobal, потому что она вводит в заблуждение. Это быстрый хакерский способ сделать что-то, что, скорее всего, будет лучшим способом.
$_POST
Например, если вы измените значение , то вы говорите, что программное обеспечение получило данные, которых оно не получило.НАСТОЯЩАЯ ПРОБЛЕМА
В реальной жизни возникает большая проблема:
Представьте, что вы работаете в команде. В идеальном мире каждый использует один и тот же синтаксис, но мы не живем в идеальном мире. Один разработчик, Джон, любит получать доступ к опубликованным данным с помощью
$_POST
. Он что-то меняет в постах:Затем у вас есть другой разработчик, Крис, который предпочитает использовать
filter_input
для доступа к введенным (то есть GET, POST, SERVER, COOKIE) данные, поскольку они защищают программное обеспечение при обработке данных, которые пользователь может подделать. В своей части программного обеспечения ему необходимо получить стоимость сообщенияranking
. Его часть кода - ПОСЛЕ Джона.Из приведенного выше примера, изменив суперглобальный, вы нарушили PHP. Джон установил значение
$_POST['ranking']
2 по любой причине, но теперь Крис получил значение 1Когда я не видел другого способа сделать это:
Я работал над проектом, который использовал Wordpress в качестве своего блога за балансировщиком нагрузки AWS. Это меняет значение
$_SERVER['remote_address']
. В этом случае у другого разработчика не было выбора, кроме как сделать следующее:Вывод
Существует почти наверняка лучший способ, чем изменить суперглобальные
источник
Я думаю, что реальный вопрос здесь «почему вы должны изменить тему?». Я не вижу веских причин для этого. Если вам нужно очистить данные, вы можете использовать локальную переменную ...
Если ваш код не является достаточно коротким (скажем, длиной менее 50 строк), изменение этих суперглобальных элементов сделает ваш код сложнее поддерживать и понимать.
Кстати, вам не нужно передавать $ _POST в функцию, поскольку это суперглобальный массив, доступ к которому можно получить даже в пределах локальной области функции.
источник
$_POST
данных? Передача$_POST
делает функцию дезинфекции любых данных.После первоначального ответа на этот вопрос, сказав, что не должно быть никаких причин изменять суперглобальные переменные, я редактирую этот ответ на примере времени, когда я решил это сделать.
В настоящее время я работаю над таблицей базы данных для перезаписи URL, посредством которой
request
столбец направляет пользователя к соответствующемуtarget
столбцу.Например,
request
может бытьblog/title-here
иtarget
может бытьblog.php?id=1
.Поскольку
blog.php
ожидаются$_GET
переменные, а я не хочу их менятьheader("Location:")
, мне осталось сделать что-то вроде этого:Это создает
$_GET
массив, содержащий предполагаемые параметры, передаваемыеtarget
столбцом.В конечном счете, я бы настоятельно рекомендовал не изменять суперглобальные переменные, если вам это не нужно .
источник