ok. i'm well aware of the perils of register_globals ON. i set my local dev server to register_globals OFF and on all of the live sites i run i set it OFF via custom php.ini.

the problem is if you are writting a PHP app for distribution that will run on a wide variety of PHP installs then you need your code to run properly with register_globals ON or OFF. most code that is register_globals OFF compliant should run fine in a register_globals ON environment. however there is one small bug/feature involving sessions and register_globals ON.

do this test script with register_globals ON:

<?php
session_start();

$_SESSION['var'] = 'test1';
$var = 'test2';
echo $_SESSION['var'];
?>

when the page is refreshed the above script outputs "test2" even though the session var was only set to "test1". the problem is that any session variables that share the same name as global variables will change values with the global variable (as if always passing by reference). i have known about this bug for a while but i always been able to work around it via turning OFF register_globals. but again, if you are designing an app to run on all servers what is the best solution to this? register_globals cannot be turned OFF at runtime via ini_set(). i am also aware of the session.bug_compat_42 directive but this does not make any difference.

can we simply not use the same variable names in sessions and in the global scope? that's seems pretty impractical. is there something obvious that i am missing that would effectively mitigate this problem?

any thoughts?

    Aren't PHP variables case sensitive? If so, wouldn't you be able to say all session vars have the format of lowercase, and all other vars have the first letter uppercased? It's weird, but it would work. You could also use an underscore at the beginning (not two, as the magic_quotes being on could possibly interfere). Just some ideas....

    ~Brett

      I get

      test1

      as expected.

      If it's a bug it ought to be listed. Let's see... http://www.php.net/changelog
      Right up the top:

      Version 4.4.1
      31-Oct-2005
      Fixed possible GLOBALS variable override when register_globals are ON.

      Indeed there is a bug, and it's been fixed. In fact at the time of writing the very top item in PHP.net's news is:

      PHP 4.4.1 Released

      [31-Oct-2005] PHP 4.4.1 is now available for download. This version is a maintenance release, that contains numerous bug fixes, including a number of security fixes related to the overwriting of the GLOBALS array. All users of PHP 4.3 and 4.4 are encouraged to upgrade to this version.

      So the real fix would be to upgrade. Otherwise you'd end up bogging down in idiotic bug-compatible fixes that you'll need to maintain into the indefinite future.

        I bow to teh awesome power of Señor Curmudgeon...

        ~Brett

          Weedpacket wrote:

          So the real fix would be to upgrade. Otherwise you'd end up bogging down in idiotic bug-compatible fixes that you'll need to maintain into the indefinite future.

          i can upgrade. but, again, if one wants to build a distrubuted app that runs on a wide variety of servers then that might be a problem. i was hoping to have the minimum system requirements be PHP 4.1.0 but i guess not.

          btw: this bug seems to still be present in PHP 5.0.5

            Well Mike, I know that using the same var name for different vars can lead to some slick coding shortcuts, but your problem demonstrates one of the costs of such a coding practice; especially in a language that does not allow you to enforce passing vars 'by value'.

            Seems to be the case that globally unique var names are once again the best option.

              one workaround that i did think of was to simply nest the session array one level deep. for example:

              // instead of this
$_SESSION['var'] = 1;

// do this
$_SESSION['data']['var'] = 1;

              that way $var will never conflict with $_SESSION['data']['var']. all that is required it that you never use a global var called $data.

                you could build your own session handler object and be done with sessions all together. lots more benifits come as icing on the cake.

                  But still, you are required not to use a global var. It's all great in theory, but it's impractical. Why woudl you want to limit yourself?

                  I revert back to my previous post:

                  Brett wrote:

                  Aren't PHP variables case sensitive? If so, wouldn't you be able to say all session vars have the format of lowercase, and all other vars have the first letter uppercased?

                  PHP Manual wrote:

                  Variables in PHP are represented by a dollar sign followed by the name of the variable. The variable name is case-sensitive.

                  Variable names follow the same rules as other labels in PHP. A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores.

                  Seems to me to be the best option if you're coding for all kinds of servers, and you need it to be compatible. Also, if you're only developing that app, then I'm sure you can go ahead and remember for the few months that you need to have uppercase variables, then your app would be perfectly fine.

                  Don't trust me (or the php manual)? Try this:

                  <?php

$var = 'A lowercase variable!!';
$Var = 'A variable with an uppercase!!';
$VAR = 'An all uppercase variable!!';

echo $var.'<br>'.$Var.'<br>'.$VAR;

?>

                  It outputs:

                  A lowercase variable!!
A variable with an uppercase!!
An all uppercase variable!!

                  Hope I can shed some light....

                  ~Brett

                    devinemke wrote:

                    btw: this bug seems to still be present in PHP 5.0.5

                    Good thing I'm still using 5.0.3 to develop, then. Perhaps you need to check to see just how widespread this bug is?

                      Write a Reply...