On October 2, 2002 02:31 pm, Sascha Schumann wrote:
> > believe should be addressed. The problem being that session_register()
> > function does not work unless the user has register_globals enabled.
>
>     I think there is a misunderstanding with regard to how
>     sessions interact with global variables.
>
>     The session extension makes use of globals only, if
>     register_globals is set.
>
>     Your patch creates references between track and global
>     variables, even if register_globals is not enabled.

>     Prior to 4.3, the session module did not create any
>     references upon session_register() in the register_globals=1
>     case.  This however is necesssary to make get_session_var()
>     reliably work and avoid any lookups in the global sym table.
>
>     Because this behaviour is new, I don't see how existing
>     applications could break.

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.
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. 

Ilia

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to