> 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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
