Skip to main content

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



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


Comments

  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.

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

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

    ReplyDelete
  4. I personally dislike dupe variables. Stick to what you got until u need to drasticly transform it. Dupe variables makes it harder to track and just wastes memory and time. Why bring sand to the beach.

    select * from tbl where this = '". mysql_real_escape_string(trim($_POST['that'])) ."'

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex