Tom's Guide | Tom's Hardware | Tom's Games
 |
 |
 |
My question has to do with PHP and using the post method for forms. I've been taught and always believed that to access these variables I had to use $_POST. But recently I was shown that I can use just the name of an item. For instance if a hidden value had the name command I could use the variable $command where ever my form was sent to. My question then is, what is the point of using $_POST? Is there an advantage to using it because all I know is that to me the code will be a lot cleaner without it.
you don't have to use $_POST if you have register_globals on. check by:
echo ini_get('register_globals'); // 0 = off
As you might've guessed, turning it on may makes things simpler for some people but I prefer to turn it off as there're potential trouble if it's on.
If it's on, I cannot use the same name for any $_POST, $_GET, $_SESSION, and $_COOKIE variable.
Also, if it's on, I need to be careful more on the code structure as every visitor can now just put site.com/?any_var_here=any_value_here to fill in any variables in the script.
0 
Use the superglobal ($_POST). Some reasons why:
- It makes the code easier to read.
- It forces the programmer to work with every input variable, all of which should be verified in some way anyway (if used).
- Automatic variables pollute the namespace.
- It's more efficient to localize only the variables you need, not the entire form.
- register_globals is disabled by default in 4.2.x onwards.
- register_globals a ridiculous security hole and is avoided by many webhosts.
0
Thank you for your input. Laler, I'm not quite understanding what you mean by not being able to use the same name for $_POST, $_GET, etc.
0
for example, this below won't work (at least won't work as we expected):
$var = $_POST['var'];
$_SESSION['var'] = 'foo';
echo $var;in the above, the output will always foo no matter what you put in the previous form field with the name "var". Newer value override old values in GET, POST, Cookie, Environment and Built-in variables.
As anonproxy suggested, it pollute the namespace :)
And taken from the comment in php.ini:
You should do your best to write your scripts so that they do not require register_globals to be on. Using form variables as globals can easily lead to possible security problems, if the code is not very well thought of.
0
Alright, I understand now. Thanks for explaining it to me. I've always used _POST and I guess I'll stick with it. I'll point it out to my partners so we can prevent any glitches. Thanks to all.
0
still, you seems to have register_globals on. if the code isnt well structured then there'll be some security risk:
<?php
// assumed this is an admin only page.
// admin status is already defined
// on previous login page, set in a
// session named 'userlevel'.if ($_SESSION['userlevel'] > 5){
$admin = TRUE;
}// in the above, if $userlevel is below 5
// then $admin is undefinedif ($admin == TRUE){
// show admin page
}else{
die();
}// in the above, the user can simply put
// some_admin_page.php?admin=8
// and $admin will be true
// thanks to register_globals :)
?>
register_globals can't be turned off from the script because it must be set before the parsing starts. It can be set in php.ini. Some hosting company allow their clients to have custom php.iniOr I think it can also be set from .htaccess but I'm not sure
http://www.google.com/search?q=register_globals+htaccess
0
I mean,
the visitor can simply put:
some_admin_page.php?admin=TRUE
:::::
admin=8 will also render $admin as TRUE, but that example is not what I'm trying to explain in the above script :D
0  |
 |
 |
This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |
