Is it preferred to assign POST variable to an actual variable?
One risk you might be running is dealing with raw user data, still saved in the raw
$_POST variable. I tend to save all the raw data I work with to other variables, like you mentioned with
$username = $_POST['username'] so I can manipulate and sanitize that input more efficiently. Rather than save any adjustments I make to the global
$_POST array, all my changes are saved temporarily and at a more manageable scope.
$username = mysql_real_escape_string($_POST['username']);
... is better than:
$_POST['username'] = mysql_real_escape_string($_POST['username']);
It's generally better to leave the raw user data as is and make your adjustments in other variables.
I see no advantage or disadvantage. Once you start modifying the values, you should put them into their own variable, but if you're just reading them, you can leave them where they are. Only two points:
- If it makes your source code more readable to use short variables names instead of
$_POST[...], that's a good reason to put the values into their own variables.
Don't necessarily take values out one by one, but just assign the array contents into another array:
$values = $_POST;// not:$foo = $_POST['foo'];$bar = $_POST['bar'];...
Assigning it to another variable will serve you well when you decide to implement another method of input (json-encoded posts, xml-rpc, soap, etc.). Making sure you get what you need from the
$_POST array at the start early on and working with those values later will make it easier to reuse the code with those other inputs: the only thing that needs to change is the instantiation of those inputs.
Also, often you want to change a value somewhat (default
trim()-ing, etc.), which is better done on a local variable then an item in a
$_POST array. Certainly on bigger projects with dozens of coders it is in my opinion a good practice to always keep the
$_POST array as received, and not fiddle in it directly infuriating a hopelessly debugging coworker...
The risks and errors do not change: it is still user-input which you should never trust, and always assume the worst case scenario of. Standard SQL-injection, XSS, and other attacks are not prevented with the practise alone.