My book tells me because they're more precise (you know where they came from) and because they're global, it's best to go with, for example $_POST['name'] instead of $name.

I understand the logic behind it, but the typing is pretty tedious . . .

Then I found this at the top of a script off the Internet:

  $name = $_POST['name'];
  $email = $_POST['email'];
  $comments = $_POST['comments'];
  $makepublic = $_POST['makepublic'];

Sure makes the rest of the script easier to type, but is that good form? Would you do it that way?

    its ok to do something like that since it will shorten your typing later especially if you will use a variable many times.
    the other reason using $POST (or any other superglobal) is because the default configuration of php for many versions now has been setup so register_globals (the setting that automatically puts $POST['name'] to $name) is switched off. therefore, as far as portability goes its best to do it. also there is some security involved as well.

    take the following

    if ($autorized == true) {
  //sensitive data here
} else {
  echo "go away";
}

    that simply checks for a value of authorized being true, which could come from a session or checking in a database.

    a person could simply call protected.php?authorized=1 and that snippet of code would show the sensitive data. with register_globals off however, $authorized and $_GET['authorized'] would be two completely different variables and that script would still say go away.

    as long as you know what data is coming from get or post and you check it for invalid values or run it through functions to make it impossible to do sql injections or execute code, you are ok

      Big-time thanks, that helps shed more light. Only thing I'm confused on . . .

      with register_globals off however, $authorized and $_GET['authorized'] would be two completely different variables and that script would still say go away.

      Wouldn't $GET still allow someone to feed that ?authorized=1 through typing it in the address bar as opposed to $POST?

        yeah it does, but with register_globals off,

        script.php?authorized=1

        creates a variable $_GET['authorized'].

        the code

        if($authorized == 1) would then evaluate false since $authorized is not the same variable as $_GET['authorized']

        register_globals being on and automatically converting $GET['authorized'] to $authorized is where the problem occurs. you have no way to tell what 'authorized' you are dealing with, it could be $GET['authorized'] $POST['authorized'] $SESSION['authorized'] or even $_COOKIE['authorized']

        register_globals helps keep those variables separate so attacks like that do not work

          I say you should protect the variables being used for the $_POST values. Such as this...

          function clean($data)
{
  return htmlspecialchars(addslashes($data));
}

$name = clean($_POST['name']);
$email = clean($_POST['email']);
$comments = clean($_POST['comments']);
$makepublic = clean($_POST['makepublic']);

          Doing this kind of method is sure to prevent all forms of posted SQL attacks/injections. Trust me, I always think security instead of structure. Its always the best way to go.-

            Cool . . . my first function. My book hadn't even gotten to that yet.

            I'm going to guess it's not coincidence you both place such an emphasis on security 😉

            I appreciate you both taking the time.

              Actually, I hadn't mentioned it, but the only way I was able to get the code to work was to comment out the first four lines.

              For some reason, when I try to add the first four lines, I all the strings are blank, resulting in 3 "you forgot to's".

              <?php

  #$name = $_POST['name'];
  #$email = $_POST['email'];
  #$comments = $_POST['comments'];
  #$makepublic = $_POST['makepublic'];

  echo '<div align="center"><br>';

  If (strlen($name) > 0) {

$name = stripslashes($name);

  } else {

echo "<p><b>You forgot to enter your name!<p><b>";

  }

  If ( !(strlen($email) > 0) ) {

echo "<p><b>You forgot to enter your email address!<p><b>";

  }

  If (strlen($comments) > 0) {

$comments = stripslashes($comments);

  } else {

echo "<p><b>You forgot to enter your comments!<p><b>";

  }

  If ($name && $email && $comments) {

If ($makepublic == "Y") {

  $not = NULL;

} else {

  $not = " NOT";

}

echo "<p><b>Thank you for your comments, $name.  You have
  chosen$not to make your comments public.</b></p>";

echo "<p><b>We should be able to reply to you at $email within a few hours.</b></p>";

$comments = wordwrap($comments, 70);

$sendtext = "name: $name\n\n";
$sendtext .= "email: $email\n\n";
$sendtext .= "comments: $comments\n\n";
$sendtext .= "make public: $makepublic";

mail("joe@schmoe.com", "Comment Form", $sendtext, "From: $email");

echo '<br><div align="center"><a href="http://www.schmoe.com/index.html">
  <p><b>Click here to return to Schmoe's home page.</b></p></a></div>';

  } else {

echo '<br><div align="center"><a href="http://www.schmoe.com/comments.html">
  <p><b>Click here to return to the comments form.</b></p></a></div>';

  }

  echo '</div>';



?>

                Probably the first logical question would be to ask if I have the proper method in my .html, but I think I do as far as I can tell . . .

                <form method="post" action="sendmail.php">

                  you can always try
                  print_r($POST) to see what it contains. but what php version are you using. if its older $POST may not have existed and you should use $HTTP_POST_VARS

                    Well I'll be a son of a gun! My cheap webhost must still be running version 3. (Shoot, I even read that at the beginning of the book but it didn't dawn on me.) Thanks for pointing that out!

                      Actually, they say they have PHP 4, I guess it was 4.1 or 4.2 where they changed the naming there . . .

                        heh yeah, dont let them saying they have php4 fool you into thinking they are up to date. 4.1.0 which was when they changed to $_POST came out in December 2001!

                        this type of problem is common and it will start to dawn on your more as you become more used to php and use it a lot. ive been doing it 4 years so a lot of these common problems stick out to me.

                          Well, it's only been 3 1/2 years, maybe they're still getting around to it. :rolleyes:

                          It seems like a no brainer for the web host to make the upgrade when it costs nothing to upgrad an open source language, but I guess if you've got like 10,000 clients on 1,000 hosts, you might just figure 4.0.6 is good enough.

                            Write a Reply...