Re: REVIEW: Imminent session patch

> Its very simply really, as you well know, since PHP 4.2.0 register_globals are > off by default. Because they are off, session_register does not retrieve a > value from the variable and only creates a null variable inside the session. > So, unless the user is aware of this issue and knows that to fix the problem > they need to enable register globals, which somewhat of a security risk, the > application they are trying to use won't work. Session is a fairly popular > extension, it is used by many PHP applications, so this is rather serious > problem. You fail to see that an application is either designed to work with enabled register_globals, or it is not. There is little in between. If an application's session part fails because of register_globals, the rest of the application which handles input data will also fail. No magic code in the session extension will cure the support hassle created by the register_globals change. The main goal is to have a stable session extension with little to no behavioral changes from 4.2 to 4.3. Please keep that in mind. > My patch does not force the association between track and global variables all > the time, it is conditional on register_globals being enabled. This does not > prevent the user from having $test0 & $_SESSION['test0'] as 2 seperate > varaibles containing unrelated data. That's incorrect. Consider this code with your patch applied and register_globals=0: $c = "bla"; session_register("c"); // $_SESSION["c"] is now a ref to $c $_SESSION["c"] = "other stuff"; // voila, you now have changed the global variable $c - Sascha