Предпочтительно ли назначать переменную POST фактической переменной?

Я только что заполнил свою регистрационную форму для своего веб-сайта и для страницы действий, где происходит весь SQL-процесс. Я просто пропустил присвоение переменной POST фактическим, например …

$ username = $ _POST ['username'];

Вместо этого я просто использовал переменные POST на странице PHP. Существуют ли какие-либо риски или ошибки, которые могут быть достигнуты во время практики?

Кроме того, извините, если я использую неправильную терминологию …

Один из рисков, который вы, возможно, выполняете, имеет дело с необработанными пользовательскими данными, которые все еще сохраняются в исходной переменной $_POST[] . Я имею тенденцию сохранять все необработанные данные, с которыми я работаю, с другими переменными, например, вы указали с $username = $_POST['username'] чтобы я мог более эффективно манипулировать и дезактивировать этот ввод. Вместо сохранения каких-либо корректировок, которые я делаю для глобального массива $_POST , все мои изменения сохраняются временно и в более управляемой области.

Например:

 $username = mysql_real_escape_string($_POST['username']); 

… Это лучше чем:

 $_POST['username'] = mysql_real_escape_string($_POST['username']); 

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

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

  • Если это делает ваш исходный код более читаемым для использования коротких имен переменных вместо $_POST[...] , это хорошая причина для того, чтобы значения были введены в их собственные переменные.
  • Не обязательно принимать значения один за другим, а просто назначать содержимое массива в другой массив:

     $values = $_POST; // not: $foo = $_POST['foo']; $bar = $_POST['bar']; ... 

Присвоение его другой переменной будет вам хорошо, когда вы решите реализовать другой метод ввода (json-encoded posts, xml-rpc, soap и т. Д.). Убедившись, что вы получите то, что вам нужно от массива $_POST в начале работы, и работа с этими значениями позже упростит повторное использование кода с этими другими входами: единственное, что нужно изменить, – это создание этих входов.

Кроме того, часто вы хотите немного изменить значение (по умолчанию trim() -ing и т. Д.), Что лучше сделать для локальной переменной, чем элемент в массиве $_POST . Конечно, в крупных проектах с десятками кодеров, на мой взгляд, хорошей практикой всегда держать массив $_POST виде , в каком он был получен , и не впадать в него, напрямую приводя в бегство от безнадежно отлаживающейся коллеги …

Риски и ошибки не меняются: он по-прежнему вводит пользователя, которого вы никогда не должны доверять, и всегда принимайте наихудший сценарий. Стандартная SQL-инъекция, XSS и другие атаки не препятствуют практике.

Мне лично не нравятся переменные обмана. Придерживайтесь того, что у вас есть, пока вам не понадобится радикально трансформировать его. Переменные Dupe затрудняют отслеживание и просто теряют память и время. Зачем приносить песок на пляж.

выберите * из tbl, где this = '". mysql_real_escape_string (trim ($ _ POST [' that ']))."