On Mon, June 12, 2006 7:22 am, João Cândido de Souza Neto wrote: > "Mk" <[EMAIL PROTECTED]> escreveu na mensagem > news:[EMAIL PROTECTED] >> Hey gang, >> >> I was having the weirdest problems when I decided to update the >> code >> for my site(written in PHP) last modified over a year ago. The code >> ran >> fine under my home development system, but on the hosting >> machine(1and1.com), my code would break. Horribly. >> >> I narrowed the problem to this - If I have a variable in >> $_SESSION(for >> example, 'username') and in my page, I declare a variable (for >> example >> '$username="guest"'), I've effectively accessed and overwritten the >> session variable. It's been over a year, but I believe this is due >> to >> magic_quotes_gpc flag being 1 or something - I checked with my >> host's >> phpinfo page and it is set to 1. >> >> My question is(before I send my host an e-mail to ask them to >> turn it >> off for my site) is, magic_quotes_gpc IS the culprit, right? I mean >> the >> whole behavior of if you declare a variable : >> >> $_SESSION['username'] = "Mark" >> >> >> then you can just write $username instead of >> $_SESSION["username"] to >> access the session variable is because of magic_quotes_gpc?
There was a bug in some release or othere where $_SESSION strings were somehow being "leaked" into PHP userland space as "string references" -- which aren't even defined in PHP userland, but that's what they were. magic_quotes_gpc on/off would probably not help, as the bug went more like this: $foo = $_SESSION['foo']; //$foo is now a REFERENCE to the session data. . . . $foo = 42; //$_SESSION['foo'] just got changed Your webhost needs to upgrade, if they are running this old buggy version... Turning OFF register_globals *MIGHT* "fix" it, in that the bug could have been triggered solely by register_globals being "ON"... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
