Newbie: My vars won't show

[LaundroMat]

Hi all,

I've just started with PHP (coming from ASP, yay another convert), and to my shame I must admit I'm already stuck on forms....

Suppose:

<form action="login.php" method="GET" title="login_form">
Login: <input type="text" name="login" size="20" maxlength="20" ><br>
Password: <input type="password" name="password" size="20" maxlength="20"><br>
<input type="submit">
</form>

And in login.php:

<?PHP
printf ("Hi, %s", $login);
printf ("Password is: %s", $password);
while (list($name, $value) = each($HTTP_GET_VARS)) {

echo "$name = $value<br>\n";

}

?>

Why, oh why do my variables show up in the while loop, and not in my printf statements?

tia

[usban]

I don't know why but how about using "echo" instead of printf??

The usage of echo is really simple.

Maybe it doen't woks because the variables passed from another paga are not treated as strigns (%s), I don`t know. :confused:

[LaundroMat]

No, I tried echo before that (just tried again, too) and it doesn't work.

Thanks for the try though :)

[ScottBP]

Tia,

In login.php try:

echo "Login: ".$login."<br>\n";
echo "Password: ".$password."<br>\n";

printf ("Hi, %s", $login);
printf ("Password is: %s", $password);


I hope this helps.

Scott

[LaundroMat]

No, still no output, except from within the "while" loop...

Why the dots before and after the variable?

(btw, my name's not Tia, tia's just short for "thanks in advance" ;))

[LaundroMat]

I feel this problem is related:

<?PHP printf("<a href=\"%s?action=news\">", $PHP_SELF) ?>Post/edit news</a>

results in this URL:
http://localhost/admin/?action=news

as you see, without the $PHP_SELF string attached.

[usban]

Try with something like this:

$HTTP_GET_VARS["login"]

as you use the get method you can see the values of the variables in the URL when going to the other page.
If it continues without going try using the POSt method instead, but it is not a reason

[Nightfire]

Yep, it should be that if the while loop is working.

[firepages]

are you working locally or is this your online server ? the issue is with the php.ini setting

register_globals which appears to be set to Off in your hosts configuration
if you are working locallay you can change this to

register_globals=on

in your c:\WINNT(windows)\php.ini

however you should still be able to access POST variables via

$_POST["variable_name"];or $HTTP_POST_VARS["variable name"]; (depracated)

as for PHP_SELF you can use $_SERVER["PHP_SELF"]; or $HTTP_SERVER_VARS["PHP_SELF"];

check out the register_globals issue and other predefined variables at http://www.php.net/manual/en/language.variables.predefined.php

[LaundroMat]

Thanks peeps, it works.

I haven't tried putting the global vars on, as in php.ini it is said that:
; 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.
Could anyone explain this to me? Afaik, this means that you should always double check the form vars and where they come from, as someone could easily "fake" them (eg changing the values of variables in a GETed url). Or are there other things to consider?

Btw, is the PHP_SELF problem related to the global_vars parameter?

[firepages]

register_globals has been turned to 'off' for some subjectively non-existant security concerns that were thown around by many 'tech-security-journalists' who obviously saw an exploit for a badly written application somewhere and then managed to turn it into something it is not.

Its true that turning register_globals=Off can overcome sloppy coding techniques... eg


<?
$yaks=mysql_query("SELECT id from auth where user='$user' AND pass='$pass'");
if(@mysql_num_rows($yaks)){$auth=1;}

if($auth==1){
//do admin type stuff//
}
?>


so with the above the url ...domain.com/admin/admin_script.php?auth=1

would give anyone access to admin functionality.

with register_globals=off the $auth var in the code is different from the $_GET["auth"] var created from the URL

that said !! anyone writing code like the above auth script is likely to have other holes lesft right and centre waiting to be exploited and register_globals=off gives no more than a false sense of security.

but after saying that :) , I kinda like the super_globals now as I have gotten used to treating

$_GET["var"];
$_POST["var"];
$var;

as 3 totally different variables , and find some advantages to this.

another common mistake is the way you use possibly manipulated data, i.e.

...file.php?file='image1'

which you may mean to use as

include($_GET['image1'].'.jpg');

but if someone changes the URL to say file.php?file=admin/password.txt

I mean unlikely but you get the point :)

also do a search in these forums or google for 'SQL injection' which is a post all of its self

................

the $PHP_SELF thing should be the same issue , use $_SERVER["PHP_SELF"]; instead.

[LaundroMat]

I see. Well, I'll leave the global_vars off, as the above solution works fine and the $_POST var is now firmly lodged in my head :) And indeed, the superglobals concept should prevent mingling variables (something that happened all too often in ASP).

But I see what you mean; in my ASP days, I already considered URL spoofing and tried to create code reacting to that. So, I'm safe there (I hope).

Top reply, thanks to all for the help & support. Another forum has been added to my "I-can't-live-without-a-daily-check-up"-list :thumbsup: