Hello,

I've been plugging away through the book and was having the hardest time working around the register_global OFF situation. I scoured this board and pieced together the way to refer to variables and the even trickier arrays. However, recently while in a bookstore and thumbing through another PHP book I found a section that talked about this issue and suggested the way around this was to use an "extract" command at the beginning of the script:

i.e. extract($_GET);

I've tacked this on to my scripts and they all work perfectly with the code verbatim from the book.

Can somebody please advise as to whether this is advisable to use this command? It obviously works but recall Nik's extensive writing on security issues and wanted to know if this was safe considering the register_global is still OFF.

Thanks in advance for the insight.

Peace,
MTG

Well, using extract($_GET) creates global variables from your $_GET indexes. It's not as terrible as having register_globals = off.

Here's the PHP code that mimics the functionality of extract():

function extract(& $var) // $var is passed by reference
{
    if (!is_array($var)) return;

    foreach($var as $key => $val)
    {
        $GLOBALS[$key] = $val;
    }
}

Keep in mind that if you use extract() to create global variables from the other superglobals (or any arrays, for that matter), you introduce the possibility of creating naming conflicts, where some variables might be overwritten by others if their names are the same.


To sum up: If you use extract() carefully, you won't run into problems. This is a clean solution (one that I've suggested in the past, actually) to getting the scripts in the book to work, but I strongly recommend against using this approach when creating real sites.


Take care,

Nik
http://www.bigaction.org/

Ah, thanks Nik. That is informative and helpful. Since I'm a newbie I have much to learn but every little bit of info helps.

Cheers,
MTG

Hello again Nik,

So of course after successfully using the extract command on a bunch of examples from the book and getting a partial validation from you, I've hit a snag. The cookie_test example won't show display the cookie says results after refresh and the page count example doesn't keep track of how many times each page has been visited.

I double checked the code and even used the downloaded code with the appended extract command. I even tried pasting in your recommendation below and still no luck.

Is this an example of a naming conflict the you mentioned might happen?

Any insight as always is appreciated.

Best,
MTG

Well, for that example, you probably need to extract($_COOKIE) instead of (or in addition to) $_GET and/or $_POST.

It's possible that there's a naming conflict coming into play if you're extracting these variables in the wrong order, too.

The default extraction order is GET, POST, COOKIE, SERVER. Look at the variables_order directive in your php.ini to see where I'm getting this from.


Take care,

Nik
http://www.bigaction.org/

Right again you were on the cookie issue. I didn't realize that could be done. Learn something new everyday.

As far as the page_count one goes it seems that extract is not the way to go as sometimes when testing an apache message would appear saying something along the lines of the script being outdated and only used up to a certain version of PHP.

...HUH?? Can you post that message, or possibly even send a screenshot of that message to me? I'm really curious to see what you're talking about.

Extract() simply copies variables from an array into global scope. That's all. Using extract() should have NO effect on whether or not the cookie variables exist or whether the script is "outdated".

The only thing I can think of is that you're seeing a "Page is expired" dialog, which means you're trying to refresh a page (or go back to a page in your history) that you submitted POST variables to.

You get the message saying the page is expired because the browser knows that the page was probably generated after processing form input -- the dialog you're getting is prompting you to resubmit the SAME form input data that you submitted the first time you viewed the page with the assumption (or hope?) that resubmitting the same form inputs will generate the same page and NOT have any weird side effects.

An example of a page with side effects:


<form method="post" action="register.php">
  Username: <input type="text" name="user" /><br />
  Password: <input type="password" name="pass" /><br />
  <input type="submit" value="Submit" name="submit" />
</form>


<?php // register.php -- registers a new user

$errors = array();
if (!isset($_POST['user'))
{
    $errors[] = "Username required!";
}
if (!isset($_POST['pass']))
{
    $errors[] = "Password required!";
}

if (empty($errors))
{
    mysql_connect('localhost', 'user', 'pass');
    $query = "INSERT INTO users (username, pass) "
           . "VALUES ('{$_POST['user']}', '{$_POST['pass']}')";

    $result = mysql_query($query);

    if (0 == mysql_affected_rows($result))
    {
        errors[] = "User already exists!";
    }
}

if (!empty($errors))
{
    echo "<b>" . join("<br />", $errors) . "</b>\n";
}
else
{
    echo "User created.";
}

?>


See, the first time you submit that page, you create the user. The second time you submit that page, you'll get the "user already exists" error. You'll also get the "page expired" error from the browser.

Okay, done rambling. Need sleep now.


Take care,

Nik
http://www.bigaction.org/