On October 2, 2002 03:46 pm, Sascha Schumann wrote:
> > 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.
In this case, would it not be prudent to either depreciate the
session_register() function or add an E_NOTICE message in the event it is
used on a system with session_register() disabled?
That way we can atleast provide the users some idea as to why their code is
not working and perphaps make the 1st step towards eliminating
session_register() completely at some point in the future.
> > 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
That is quite correct. Of course it can be avoided by some additional hacking
to the code. However, based on your defenition of the goals for the session
extension, I believe it would be quite useless.
Ilia
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
