Re: Re: Bug #14540 Updated: sessions and register_globals

Hello, On Sun, 16 Dec 2001, John Lim wrote: > Doesn't this seem counter-intuitive? Can we improve the implementation > somehow? It does not to me, you need to check if $PIPPO exist in the session, and the only way (when register globals is off) is to do that with isset ($_SESSION['PIPPO']). Derick > > Regards, John > > <derick@php.net> wrote in message > news:20011216103214.17432.qmail@php2.chek.com... > > ID: 14540 > > Updated by: derick > > Reported By: bilo@bilo.dnsalias.net > > Status: Bogus > > Bug Type: Session related > > Operating System: linux 2.2.18 - glibc 2.1.3 > > PHP Version: 4.1.0 > > New Comment: > > > > Oops, > > > > here is the explanation: > > > > the function 'session_register()' 'registers' a variabele to a > > session. In > other words, when the script ends, the value of this variabele is stored > with the session. > > > > On the first run $PIPPO is empty (of course), and it is set to 'ONE'. > > At the end of the script, the value is stored in the session file. > > > > At the second run, (PIPPO is still registered to the session, so > session_register has no effect), empty($PIPPO) evalutes to TRUE again, > because the value is in $_SESSION['PIPPO'], and thus PIPPO is set to 'ONE' > again. > > At the end of the script, the value of $PIPPO ('ONE') is saved to the > session again. > > > > You can see more of this behavior, if you set error_reporting(E_ALL) to on > in the script. > > > > Hope this explained it, > > regards, > > > > Derick > > > > Previous Comments: > > ------------------------------------------------------------------------ > > > > [2001-12-16 05:15:53] derick@php.net > > > > Hello, > > > > let me explain this, > > > > ------------------------------------------------------------------------ > > > > [2001-12-15 22:32:36] bilo@bilo.dnsalias.net > > > > There is something I don't understand. > > > > I've updated to v4.1.0 and noticed that the recommended > > configuration defaults register_globals to *Off*. I > > understand the security reasons behind this choice. I've > > tried to run one of my projects with the new interpreter > > and the recommended settings (register_globals=Off). After > > resolving a plenty of warnings, I noticed that things were > > not working as I expected. > > > > This is a sample code: > > > > <? > > session_register('PIPPO'); > > if (empty($PIPPO)) { > > $PIPPO = "ONE"; > > } else { > > $PIPPO = "TWO"; > > } > > > > $sidfile = "/tmp/sess_" . $_COOKIE['PHPSESSID']; > > > > echo "Session file $sidfile contains: <pre>"; > > readfile($sidfile); > > echo "</pre>"; > > > > echo "The value is: $PIPPO<br>"; > > ?> > > > > > > When I run and reload the script I get: > > > > Session file /tmp/sess_87...blahblah...3e contains: > > > > PIPPO|s:3:"ONE";maxrating|N; > > > > The value is: ONE > > > > Why the first run sets the session variable to "ONE" and > > the second run can't get it's value? In the latter case I > > guess the answer is: "because you have to access it through > > $HTTP_SESSION_VARS", but ... shouldn't it had to be the > > same in the former case? > > > > > > ------------------------------------------------------------------------ > > > > > > > > Edit this bug report at > > http://bugs.php.net/?id=14540&edit=1 > > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >