you do not need to call global $SESSION; inside fo your functions. this is precisely why $GET, $POST, $SESSION, etc. are called superglobals (or autoglobals), that is, they are global everywhere without having to explicitly make them so.

as far as register_globals, it is a bad idea all around but particularly bad when dealing with sessions. changes to the global variables affect the $_SESSION index. in fact there is a well documented bug dealing with this in PHP 4.2 (look in you php.ini file under session.bug_compat_42 and session.bug_compat_warn).

    Ok, then what on earth do I do?

    I have to unset $_SESSION['mainDisplay'] and the change must take even after the method is exited; this only works if register_globals is off

    However, on one of the servers, register_globals must remain on (requirement for the server due to legacy programs) and this will break my application's functionality once I put that there!

    Phil

      you can always run a local php.ini file in your script directory with register_globals OFF.

        
        if ((int)ini_get('register_globals') === 1) ini_set('register_globals', 0);
        unset ($_SESSION['mainDisplay']);
        global $_SESSION;
        
        

        And guess what?

        print_r($_SESSION['mainDisplay']);
        

        after redirection of page STILL produces that session variable, no matter what!

        In PHP 4.3.2 with register_globals off you can alter the autoglobal value and it'll take; in PHP 4.3.6 with register_globals on, apparently, you can't, which means my application will never work in any version of PHP after version 4.3.2 with register_globals on, which is a big problem because that's the required environment for my application to be run in!

        Phil

        Phil

          Ok perhaps final update.. in index.php, the very first script ever called in my application, I did this, and I'd please like an explanation from a guru out there (DevinEmke especially) why this works:

          if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
          session_cache_limiter();
          session_start();
          

          Huh? How did I get away with this knowing that session_start() must be called first?

          Phil

            first thing you need to do is stop using global $_SESSION because its just wrong.

            second thing is look in the user comments section of the manual. I found this in there, it may help you.

            andre at twg dot com dot au
            06-Mar-2004 07:16
            Only This works with register_globals being 'ON'.

            unset( $_SESSION['variable'] );

            The above will not work with register_globals turned on (will only work outside of a function).

            $variable = $SESSION['variable'];
            unset( $
            SESSION['variable'], $variable );

            The above will work with register_globals on & inside a function

            http://us4.php.net/manual/en/function.unset.php

            • keith

              Originally posted by ppowell
              Ok perhaps final update.. in index.php, the very first script ever called in my application, I did this, and I'd please like an explanation from a guru out there (DevinEmke especially) why this works:

              if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
              session_cache_limiter();
              session_start();
              

              Huh? How did I get away with this knowing that session_start() must be called first?

              Phil [/B]

              session_start only needs to be called before any output to the browser, but session_cache_limiter is REQUIRED to be called before session_start as are any other session functions that determine how the session works.
              i.e. session_name('foo') or session_set_cookie_params(), etc.

              again, consult the bible, book of sessions.

              The cache limiter is reset to the default value stored in session.cache_limiter at request startup time. Thus, you need to call session_cache_limiter() for every request (and before session_start() is called).

              • keith

                Sorry but I meant the ini_set() line before any of the session functions.. why am I able to do THIS particular call first before session_start()?

                Thanx

                Phil

                  you cannot use ini_set() to turn of register_globals. from the manual:

                  Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals on.

                  to turn off register_globals in an environment where it is on you can do a few things. if you are using Apache and you are running PHP and an Apache module then you might be able to do the htaccess trick described above (depending on the Apache configuration). the other way is to copy the system-wide php.ini to your local public directory and change the register_globals setting there. PHP (usually) will first look in the same directory as the script being called for a php.ini, if there is none it will use the system wide one (defined at compile time: /usr/local/bin/php.ini or C:\Windows\php.ini). either way you have some options here to turn off register_globals.

                  I persoanlly am the webmaster of several sites that are hosted on register_globals ON environments. In each case the host is running UNIX/Apache/PHP as CGI. what i do is run a nightly cron job that copies the server's php.ini, make certain changes (including register_globals = OFF) and then writes it back to a file in my document root. i then use symlinks to recursively have each subdirectory point to my master php.ini.

                    That would, of course, pre-suppose I will have that kind of access on every machine this application will be put on, and this has to be a totally portable and usable PHP web application (with some XML, Bash and TCL thrown in for flavor). That means it will be on a server that may be Linux or Windows, Apache or IIS, MySQL or whatever else, and register_globals on or off and whatever PHP version exists (minimum requirement is 4.1.2).

                    If you can't turn off register_globals at runtime, how on earth am I able to turn off register_globals at runtime, and, furthermore, successfully unset the session variable by attempting to do so whereas I could not before?

                    Phil

                      Sorry but the manual has to be wrong on this one.

                      print_r(ini_get('register_globals'))); echo '<P>';
                      if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
                      session_cache_limiter();
                      session_start();
                      print_r(ini_get('register_globals'))); echo '<P>';
                      

                      in PHP 4.3.6 with register_globals ON produces:

                      1

                      I am fully capable of turning off register_globals at runtime in PHP 4.3.6. Furthermore, in my original environment of 4.3.2 I am also capable fully of turning off register_globals at runtime.

                      What can I say?

                      Phil

                        Originally posted by ppowell
                        Sorry but the manual has to be wrong on this one. I am fully capable of turning off register_globals at runtime in PHP 4.3.6. Furthermore, in my original environment of 4.3.2 I am also capable fully of turning off register_globals at runtime.

                        What can I say?

                        the manual is not wrong, it's just a little unclear. you cannot effictively turn off register_globals at runtime (is what it should say). you can call ini_set() and turn off register_globals but by then you are too late, the php.ini will have already been parsed and the global varibales will already have been created. so even though you are turning it off at runtime, it is , in effect still on. do this test: turn register_globals ON in your php.ini, create a blank test.php file and add the following code:

                        ini_set('register_globals', false);
                        $register_globals = (bool) ini_get('register_gobals');
                        if ($register_globals) {echo 'register_globals is ON';} else {echo 'register_globals is OFF';}
                        
                        echo "<br><br>$var";
                        

                        then open your browser and goto http://localhost/test.php?var=ppowell. tell me what you see. the GET variable $var with a value of "ppowell" will already be set despite you having turned off register_globals.

                          Perhaps I too am a bit unclear. I do not want to effectively turn off register_globals altogether within php.ini. On the server there will be several applications, some that require it to be on, others that will require it to be off.

                          The only way to handle this is to turn it "off" at runtime, that is, for this application (../index.php) register_globals will appear to be "off" which allows me to unset the session variable FOR THIS APPLICATION (application-level global variable redefinition).

                          That is why I know I can use ini_set() and turn off register_globals and it will be off as long as the application is evaluated and runs; moment that it stops running, the default settings in php.ini resume as if nothing ever happened and life is normal.

                          Phil

                            Write a Reply...