On October 2, 2002 04:26 pm, Rasmus Lerdorf wrote:
> I really don't see why would want to deprecate session_register().
> Regardless of whether register_globals is on or off, code like this works
> fine:
>
> Set a session var:
> session_register('a');
> $a=1;
That example only works when register_globals are on. When they are off, it
produces:
var_dump($a) -> int(1)
var_dump($_SESSION['a']) -> NULL
If register globals are enabled, then this example results in:
var_dump($a) -> int(1)
var_dump($_SESSION['a']) -> int(1)
When register_globals are off register_session('a') merely creates a NULL
entry 'a' entry inside http_session_vars. Since that is the case, would it
not be simpler to use:
$_SESSION['a'] = &$a;
$a=1;
or
$a = 1;
$_SESSION['a'] = $a;
which work fine regardless of whether register_globals are on or off.
Ilia
> Get a session var:
> session_start();
> $a = $_SESSION['a'];
>
> This makes perfect sense to me and I see no reason to change that way of
> writing session code.
>
> -Rasmus
>
> On Wed, 2 Oct 2002, Ilia A. wrote:
> > 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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
