Я только что заполнил свою регистрационную форму для своего сайта и для страницы действий, где происходит весь 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. Придерживайтесь того, что у вас есть, пока вам не понадобится радикально трансформировать его. Переменные Dupe затрудняют отслеживание и просто теряют память и время. Зачем приносить песок на пляж.
выберите * из tbl, где this = ' ". mysql_real_escape_string (trim ($ _ POST [' that ']))."