Непосредственно модифицирующие суперглобалы

Я видел людей (которые обычно пишут хороший код), которые напрямую изменяют $_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['foo'] = filter($_POST['foo']);

когда вы можете легко сделать:

$foo = filter($_POST['foo']);

Я думаю , что это гораздо более ясно , чтобы сделать общесистемное различие , которое $_POSTи $_GETбудет всегда нефильтрованными, ненадежные данные, и они не должны никогда быть использован как есть.

Копируя отфильтрованное значение в другую переменную, вы заявляете, что «я понимаю, что делаю ... Я отфильтровал этот ввод, и его можно безопасно использовать».

Я бы вообще предложил, чтобы вы не изменяли предопределенные суперглобальные переменные, чтобы было ясно, что такое очищенные данные, а что необработанные / ненадежные данные.

Другие могут предположить, что если вы очистите суперглобальные переменные в начале цикла запроса, вам не нужно беспокоиться о них в другом месте.

Я всегда сопоставляю их, когда они вам нужны:

$id = (int)$_POST['id'];

или похожие.

С точки зрения других переменных , это хорошая практика , чтобы не писать ни одному из $_GET, $_POST, $_REQUEST, $_SERVERили $_COOKIE. $_SESSIONоднако отличается, потому что вы часто хотите записать данные в сеанс, которые затем сохраняются по различным запросам в сеансе.

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

• Вы можете получить только то , что вы хотите / должны , а не то , что в $_POSTслишком
• Вы, вероятно, получите ошибку, если во вновь созданном массиве отсутствуют некоторые ключи или нет вообще

Дополнительные другие скрипты могут предполагать, что массив не тронут и может реагировать любопытно.

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

$_POSTНапример, если вы измените значение , то вы говорите, что программное обеспечение получило данные, которых оно не получило.

НАСТОЯЩАЯ ПРОБЛЕМА

В реальной жизни возникает большая проблема:

Представьте, что вы работаете в команде. В идеальном мире каждый использует один и тот же синтаксис, но мы не живем в идеальном мире. Один разработчик, Джон, любит получать доступ к опубликованным данным с помощью $_POST. Он что-то меняет в постах:

$_POST['ranking'] = 2; // John has changed ranking from 1 to 2 for whatever reason

Затем у вас есть другой разработчик, Крис, который предпочитает использовать filter_inputдля доступа к введенным (то есть GET, POST, SERVER, COOKIE) данные, поскольку они защищают программное обеспечение при обработке данных, которые пользователь может подделать. В своей части программного обеспечения ему необходимо получить стоимость сообщения ranking. Его часть кода - ПОСЛЕ Джона.

$ranking = filter_input(INPUT_POST, 'ranking', FILTER_SANITIZE_NUMBER_INT);
// $ranking = 1

Из приведенного выше примера, изменив суперглобальный, вы нарушили PHP. Джон установил значение $_POST['ranking']2 по любой причине, но теперь Крис получил значение 1

Когда я не видел другого способа сделать это:

Я работал над проектом, который использовал Wordpress в качестве своего блога за балансировщиком нагрузки AWS. Это меняет значение $_SERVER['remote_address']. В этом случае у другого разработчика не было выбора, кроме как сделать следующее:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $parts = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = $parts[0];
}

Вывод

Существует почти наверняка лучший способ, чем изменить суперглобальные

Я думаю, что реальный вопрос здесь «почему вы должны изменить тему?». Я не вижу веских причин для этого. Если вам нужно очистить данные, вы можете использовать локальную переменную ...

Если ваш код не является достаточно коротким (скажем, длиной менее 50 строк), изменение этих суперглобальных элементов сделает ваш код сложнее поддерживать и понимать.

Кстати, вам не нужно передавать $ _POST в функцию, поскольку это суперглобальный массив, доступ к которому можно получить даже в пределах локальной области функции.

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

В настоящее время я работаю над таблицей базы данных для перезаписи URL, посредством которой requestстолбец направляет пользователя к соответствующему targetстолбцу.

Например, requestможет быть blog/title-hereи targetможет быть blog.php?id=1.

Поскольку blog.phpожидаются $_GETпеременные, а я не хочу их менять header("Location:"), мне осталось сделать что-то вроде этого:

$uri    = explode('?', $uri_request)[0];
$params = explode('?', $uri_request)[1];
parse_str($params, $_GET);

Это создает $_GETмассив, содержащий предполагаемые параметры, передаваемые targetстолбцом.

В конечном счете, я бы настоятельно рекомендовал не изменять суперглобальные переменные, если вам это не нужно .