Является ли предпочтительным присваивать переменную POST фактической переменной?

Question

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

$username = $ _POST ['username'];

Вместо этого я просто использовал переменные POST по всей странице PHP.Есть ли какие-либо риски или ошибки, которые можно встретить во время практики?

Также, извините, если я использую неправильную терминологию ...

Answer 1

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

Например:

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

... isлучше чем:

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

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

Answer 2

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

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

• Не обязательно извлекать значения одно за другим, а просто назначить содержимое массива в другой массив:

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

Answer 3

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

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

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

Answer 4

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

выберите * из таблицы, где это = '". Mysql_real_escape_string (trim ($ _ POST [' that ']))."'