phplib's solution has been to re-register s globals ll the $_SESSION vars. The register_globals=Off has been placed, I suppose, to prevent GET/POST (and any user_originated) var to overwrite uninitialized program variables. As session vars are not user_originated, and only the programmer can set it, I'd let them global as always, or write my own globalizing function after session start
Sascha Schumann wrote: > > With PHP 4.3, it finally becomes possible to completely > manage session variables without any dedicated functions. > Just set or unset variables in $_SESSION and you are done > with it. It could not be any easier. > > The streamlining of the serialization process also has > another advantage -- the extension will notify developers > that their script might be indeterministic. > > How? you ask. Imagine a section of code which intents to > change a session variable. At the first execution, setting > the global works. But when the section of code is run again, > the exact same code will silently fail.[1] > > You have observed correctly that application developers have > noticed that disabling register_globals has an effect on > their session usage. Those developers have appropiately > changed their applications to read from and write to > $_SESSION. > > Now I ask you: Why should the same set of developers be > afraid or incapable of making their scripts more reliable and > not complete this transition? > > [1] I hope everyone sees how absurd it is to suggest that > these kind of semantics were actually intended by the > session authors. > > - Sascha -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
