Что не так с использованием $ _REQUEST []? - PullRequest
Новая
       23

Что не так с использованием $ _REQUEST []?

115 голосов
/ 26 января 2010

Я видел несколько постов, в которых говорилось, что не следует использовать переменную $_REQUEST. Я обычно нет, но иногда это удобно. Что с ним не так?

Ответы [ 15 ]

0 голосов
/ 09 февраля 2016

Даррен Кук:"Начиная с php 5.3 по умолчанию php.ini говорит, что только данные GET и POST помещаются в $_REQUEST. См. php.net / request_order Я просто наткнулся на этот разрыв обратной совместимости при ожидании cookie данные должны быть в $_REQUEST и интересно, почему это не работает! "

Ух ты ... только что некоторые из моих скриптов перестали работать из-за обновления до PHP 5.3 . Сделал то же самое: предположим, что куки будут установлены при использовании переменной $_REQUEST. С апгрейдом точно, что перестало работать.

Теперь я вызываю значения cookie отдельно, используя $_COOKIE["Cookie_name"] ...

0 голосов
/ 20 сентября 2011

Я думаю, что нет проблем с $_REQUEST, но мы должны быть осторожны при его использовании, так как это набор переменных из 3 источников (GPC).

Я думаю, $_REQUEST все еще доступен для того, чтобы сделать старые программы совместимыми с новыми версиями php, но если мы начнем новые проекты (включая новые библиотеки), я думаю, что нам не следует больше использовать $_REQUEST, чтобы сделать программы более понятными. Мы должны даже рассмотреть вопрос об удалении использования $_REQUEST и замене его функцией-оболочкой, чтобы сделать программу легче, особенно при обработке больших отправленных текстовых данных, поскольку $_REQUEST содержит копии $_POST. 

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}
0 голосов
/ 27 января 2010

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

Может быть удобно использовать $ _REQUEST, когда ваши скрипты могут одинаково реагировать на GET или POST. Я бы сказал, однако, что это должно быть крайне редким случаем, и в большинстве случаев предпочтительными являются две отдельные функции для обработки двух отдельных концепций или, по крайней мере, проверка метода и выбор правильных переменных. За ходом программы обычно намного легче следить, когда нет необходимости в перекрестной ссылке, откуда могут исходить переменные. Будьте добры к человеку, который должен поддерживать ваш код в течение 6 месяцев. Это может быть ты.

В дополнение к проблемам безопасности и WTF, вызванным файлами cookie и переменными среды в переменной REQUEST (не начинайте с GLOBAL), подумайте о том, что может произойти в будущем, если PHP будет изначально поддерживать другие методы, такие как PUT и УДАЛЯТЬ. Хотя крайне маловероятно, что они будут объединены в суперглобальный объект REQUEST, возможно, они могут быть включены как опция в настройке variable_order. Таким образом, вы действительно не имеете ни малейшего представления о том, что держит REQUEST и что имеет приоритет, особенно если ваш код развернут на стороннем сервере.

POST безопаснее, чем GET? На самом деле, нет. Лучше использовать GET там, где это целесообразно, потому что в ваших журналах легче увидеть, как эксплуатируется ваше приложение, когда оно подвергается атаке. POST лучше подходит для операций, которые влияют на состояние домена, поскольку пауки, как правило, не следуют за ними, а механизмы прогнозирующей выборки не удаляют весь ваш контент при входе в CMS. Однако вопрос был не в достоинствах GET против POST, а в том, как получатель должен обрабатывать входящие данные и почему плохо их объединять, так что это действительно просто BTW.

0 голосов
/ 26 января 2010

Я мог бы использоваться, только если вы хотите получить текущий URL или имя хоста, но для фактического анализа данных с этого URL, таких как параметры, с использованием символа &, это, вероятно, не очень хорошая идея. В общем, вы не хотите использовать расплывчатое описание того, что вы пытаетесь сделать. Если вам нужно быть конкретным, то здесь $ _REQUEST плох, если вам не нужно быть конкретным, не стесняйтесь использовать его. Я бы подумал.

0 голосов
/ 26 января 2010

Это очень небезопасно. Кроме того, это неудобно, поскольку вы не знаете, получаете ли вы POST, GET или другой запрос. Вы действительно должны знать разницу между ними при разработке ваших приложений. GET очень небезопасен, так как он передается в URL и не подходит почти для всего, кроме навигации по страницам POST, хотя сам по себе небезопасен, обеспечивает один уровень безопасности.

Страница:
...