Re: [PATCH] Fix for bug #31440 (GLOBALS can be by G/P/C when register_globals=On)

On Tue, 15 Feb 2005, Andi Gutmans wrote:

This behavior makes some sort of sense. It happens when register_globals is on which means you are supposed to be able to access $GLOBALS[] and it makes sense for it to stay in sync with the global variables.

    Yes, and register_globals=on is evil. That I do agree with. :)
    And that was the initial response I had in mind for this bug report too.

Maybe $GLOBALS[] and $GLOBALS direct access are edge cases but should we invest time and code to resolve this when we know it's a general problem anyway?

    Well, the patch is there and works with all cases I tried with and could
    think of..but I'm all for removing register_globals altogether though. :)

    Seriously, this is not consistent (you can't replace e.g. _GET like this)
    so why not protect against it?

    I cooked up a piece of PHP code to recreate $GLOBALS always when
    register_globals=On but come on..it's slow and won't give you exactly
    same result..

<?php /* * Protect GLOBALS by recreating it whenever register_globals = On */ if (ini_get('register_globals')) {

    $superglobals = array (
        '_SERVER' => $_SERVER,
        '_ENV'    => $_ENV,
        '_FILES'  => $_FILES,
        '_COOKIE' => $_COOKIE,
        '_POST'   => $_POST,
        '_GET'    => $_GET
    );
    if (isset($_SESSION)) {
        array_unshift($superglobals, array ('_SESSION' => $_SESSION));
    }
    $GLOBALS = array();
    foreach ($superglobals as $sg_name => $sg_value) {
        $GLOBALS[$sg_name] = $sg_value;
        foreach ($sg_value as $name => $value) {
            $GLOBALS[$name] = $value;
        }

} } ?>

    It lacks the reference to itself of course but who needs that anyway? :)
    So, do I post that as resolution for the bug or what?

    --Jani