Я только что заполнил свою регистрационную форму для своего веб-сайта и для страницы действий, где происходит весь 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 ']))."