Is it preferred to assign POST variable to an actual variable?

Question

I've just completed my registration form for my website and for the action page where all the SQL takes place I've just skipped assigning the POST variable to actual ones, like this...

$username = $_POST['username'];

Instead I've just been using the POST variables throughout the PHP page. Are there any risks or errors that can be met whilst practicing?

Also, excuse me if I am using incorrect terminology...

Solution 1

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.

For example:

$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.

Solution 2

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'];
  ...
  

Solution 3

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.

Comments

[Gromski]

$foo = $_POST wastes hardly any memory, since no data is being copied.

[tim]

I didnt say it wastes a lot of memory. Whats the real win in duping variables? Unless a split usage?

[Gromski]

Quote: "Dupe variables [...] just wastes memory [...]"... Not saying the rest of your statement isn't true, just saying that it doesn't waste memory (beyond what is necessary to store a new pointer to the values), which is what you stated. :)

[Graham Swan]

I agree with this. In vanilla PHP, I always assign POST vars to their own unique variable simply to stay organized.

[tim]

So what holds the data then? Air? Try compiling and see how many bytes get compiled. There will be a byte difference.

[Gromski]

OK, what exactly are you talking about then? The added characters in the source code? The extra entry in the symbol table? Or the actual data? Because the former two are the only things that change, and they're hardly worth mentioning.