Form value problems

[salewit]

I've got kind of a weird problem I can't figure out. I've got a form such as:

Filename=test.php


------------------------

session_start

print "<form action='test.php' method='POST'>";
print "<input type='text' name='foo' value='$foo'>";
print "<input type='submit' value='Go'>";
print "</form>";

-------------------------

This is very simplified, but the problem I'm having is that I can't seem to change the input value. Let's say I enter "abc", then I do a check for this value and determine it's wrong and send the user back to this page. "abc" is filled into the box. But if then type over "abc" and change it to say "def", the value does not change to "def". In fact I can NOT alter the initial value of "abc" no matter what I do. Does this make sense?

There must be something I'm doing wrong or have set wrong somewhere. Thanks, Sam

 

[Vragabond]

How are you checking for the value that has been sent? Are you printing out the $_POST array using print_r($_POST);?

 

[748323]

Placing:

foreach($_POST as $key => $value) {
$$key = $value;
}

in the beginning may work. Try it.

 

[salewit]

Hmmm I should have mentioned that I'm kind of a beginner at this. At first I tried to check in the beginning of my scriph such as this:

Filename=test.php

------------------------
session_start

if ($flag == 1) {
if ($foo == "abc") $error=1;
}

if (($flag ==1) && ($error > 0)) {
print "There is an error. Correct.";
header ("Location: test.php");
$flag=0;
exit;
}

print "<form action='test.php' method='POST'>";
print "<input type='hidden' name='flag' value='1'>";
print "<input type='text' name='foo' value='$foo'>";
print "<input type='submit' value='Go'>";
print "</form>";

-------------------------

Then I changed the form action to a 2nd page to check for validity, and go back if there were problems. Both ways are doing the same thing and that is not allowing me to change $foo once it's been set.

 

[Vragabond]

I still cannot see where you're setting the value of $foo. I can see that you're reading it into the value of the form element but not setting it anywhere. Also, I think your script assumes register globals on, which is bad coding practice and security hole. There's a good chance your code is not working because of that. Variables which are transmitted via form (or in any way between two pages) need to be referrenced via their designated array (depending on the method of transmition). For your code, that would be $_POST. So do something like:

if ($_POST['flag'] == 1) 
{
  if ($_POST['foo'] == "abc") 
  {
    $error=1;
  }
}

There's also a bunch of weird things in your code:

1. you're issuing session_start at the beginning of the script and not using sessions at all.
2. you're trying to redirect the browser via header() function after something was printed to the browser. That will not work, since header() must be issued before any other output.

 

[salewit]

Thanks for the response.

Ok, here's the problem. I taught myself PHP from a book. Apparently an OLD book. So now I'm in the bad position of having to unlearn before I learn properly.

This book told me that PHP passes form variables automatically. Whether POST or GET is used, the next script will have that variable set by the form automatically. Is this not correct? Shouldn't the variable $foo be set by the input tag? And be readable by the the script in the form tag?

I'm going to have to go out today and get a good book on the subject so I can finish this mess.

I abbreviated the code to make things simpler, but I guess I made it more confusing. I am storing session variables in another script and using them throughout.

Also, yes, I was aware about no output before the header function. That was weird code.

Thanks again for the help.
Sam

 

[sleipnir214]

The canonical reference for PHP is the online manual:

http://www.php.net/manual/en.

Get familiar with the online manual, it is one of the better ones out there.

If you have a form field named "foo" that is submitted to "bar.php", $foo will, by default, not be instantiated. This is a change in the behavior of the more recent versions of PHP, and is explained here:

http://www.php.net/manual/en/security.globals.php

Even if having register_globals set to "on" were not a security risk, I would recommend that you program every script as if it were turned off anyway. This is because your scripts could be run in an environment where register_globals is "on" or "off", but if you assume it's "off", your code will run in either case. Also, by using $_POST and $_GET (and the other superglobal arrays), you will have partially documented your code -- you may not remember six months from now how the value got into $foo, but $_POST['foo'] is obvious.

Some books will mentions the "long-named" arrays, $HTTP_POST_VARS, $HTTP_GET_VARS, etc. Do not use these, as they are deprecated and turned off by default in version 5.x of PHP. Also, $HTTP_POST_VARS is a global array, where $_POST is superglobal. In a user-defined function in your script, $_POST will be available, but $HTTP_POST_VARS will not. See

http://www.php.net/manual/en/language.variables.scope.php

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[dexthageek]

Try adding

if(is_array($_POST)){extract($_POST, EXTR_PREFIX_SAME, "post");}

at the beginning of your script after any header declarations.

See if that works for you.

 

[sleipnir214]

Misuse of extract() can reintroduce exactly the same problems that setting register_globals to "off" was intended to fix. It can allow the same variable poisoning to occur that is warned about in the online manual.

Anyway, what's wrong with just having your code reference $_POST['foo']?


Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[salewit]

Wow, thanks again for the in-depth help. I turned register_globals off, and now of course the thing is not running at all. I'm going through the code step by step changing things. There seems to be a lot to change.

I'll check out php.net. I've been there before, and they're great as reference material, but for a beginner their terminology can be a little rough.