[RESOLVED] Phantom register_globals...?

[ixalmida]

According to phpinfo(), register_globals is OFF. However, I have a local (or POST) variable overwriting my SESSION variable of the same name. And it gets stranger...

At no point does the SESSION variable have a value during the first page load, as it shouldn't. But if I reload the page (and re-post), the SESSION variable gets overwritten with either the POST variable with the same name (or perhaps the local variable with the same name from the previous load...but doubtful). This happens in both Firefox and IE.

Any idea what might be causing this? I'm stumped.

PHP v.5.3.1

The first two lines of code are:

session_start();
echo "<!-- ".$_SESSION['my_var']." -->";

And as I stated above, there is both a $my_var and a $_POST['my_var'] on the page. The only line of code with the word "session" in it is the "session_start()" statement, so I'm pretty sure this is happening by some magical method.

[NogDog]

Any possibility you have something set for auto_prepend_file that is including a script that emulates register_globals? You might also want to a [man]php_info/man; to make sure you're looking at the correct php.ini file. For that matter, you can do echo ini_get('register_globals'); to confirm it is on/off, so we can rule out some possibilities.

[ixalmida]

Not that I know of, but I'll check it tomorrow. It's the latest XAMPP distro. I've only made a few changes to the php.ini and .conf files where I knew I needed to.

[ixalmida]

I've narrowed the issue down to a single line of code.

// Before this line of code, $_SESSION["rg_list"]=> NULL
$rg_list = implode(", ", $_POST['region_id']);
// After this line, $_SESSION["rg_list"]=>  string(5) "12, 2"

I've checked phpinfo(), and register_globals is off before and after the statement.

The purpose of this particular line of code is to create a region ID list from the submitted page's array of "region_id" checkboxes. At no point on the page do I refer to the $_SESSION["rg_list"] variable, nor do I use any tricky scope declarations anywhere. Unless "rg_list" has some kind of special meaning to PHP, I can't understand why the SESSION variable would be overwritten.

Grrr...

[ixalmida]

I should add that this same line of code worked fine when it was running on LAMP. Unfortunately, I had to move to XAMPP because I couldn't get a necessary MS-SQL interface working correctly with any of the free drivers (records returned were flaky). Now I'm importing data from MSSQL just fine, but I've had all sorts of other problems, such as my PHP time calculations quit working (no clue on that one either - I converted them into MySQL functions, which are worry-free).

[NogDog]

ixalmida;10961056 wrote:

I've narrowed the issue down to a single line of code.

// Before this line of code, $_SESSION["rg_list"]=> NULL
$rg_list = implode(", ", $_POST['region_id']);
// After this line, $_SESSION["rg_list"]=>  string(5) "12, 2"

I've checked phpinfo(), and register_globals is off before and after the statement.

The purpose of this particular line of code is to create a region ID list from the submitted page's array of "region_id" checkboxes. At no point on the page do I refer to the $_SESSION["rg_list"] variable, nor do I use any tricky scope declarations anywhere. Unless "rg_list" has some kind of special meaning to PHP, I can't understand why the SESSION variable would be overwritten.

Grrr...

To me that sounds less like register_globals than it does some user-defined function/code that is creating a variable that is a reference to the $SESSION element, e.g. $rg_list =& $SESSION['rg_list'], though it might likely be done via variable variables, e.g.:

foreach($_SESSION as $key => $value) {
   $$key =& $_SESSION[$key];
}

[ixalmida]

I apologize for the delayed response. Yesterday was a very stressful day. Anyway...

I did a site-wide search and I only use the variable in two types of statements: 1) I use empty() to check if it has a value, and 2) I use it in query strings, i.e., "SELECT field FROM table WHERE region_id IN (".$_SESSION['rg_list'].")"

This is looking more and more to me like a bug in the latest XAMPP distro of PHP - especially when considered alongside the time calculation discrepancies, which I didn't have with the same code on the former LAMP server (same PHP version). I'm starting to wish I had talked my boss into ponying up the $1,200 for the Easysoft SQL driver.

[laserlight]

hmm... but if you suspect it is XAMPP's fault, would it be feasible for you to simply not use XAMPP?

[ixalmida]

Unfortunately, it's too late now. I had to rush this server into production to meet the timeline for the MS-SQL integration. I'll be building a fail-over server in the next week or so, so I can do something once that one is up and running.

Do you have any suggestions for the fail-over server? I don't have a lot of extra time, so I need a quick-deploy WAMP package that won't require a whole bunch of tweaking and won't be a security nightmare.

[Weedpacket]

Have the php.ini values for [font=monospace]session.bug_compat_42[/font] and/or [font=monospace]session.bug_compat_warn[/font] changed?

[font=monospace]; PHP 4.2 and less have an undocumented feature/bug that allows you to
; to initialize a session variable in the global scope, even when register_globals
; is disabled. PHP 4.3 and later will warn you, if this feature is used.
; You can disable the feature and the warning separately. At this time,
; the warning is only displayed, if bug_compat_42 is enabled. This feature
; introduces some serious security problems if not handled correctly. It's
; recommended that you do not use this feature on production servers. But you
; should enable this on development servers and enable the warning as well. If you
; do not enable the feature on development servers, you won't be warned when it's
; used and debugging errors caused by this can be difficult to track down.
; Default Value: On
; Development Value: On
; Production Value: Off
; http://php.net/session.bug-compat-42
[/font]

[ixalmida]

Good call, weedpacket! Those appear to both be enabled by default. It looks like they should be disabled. I can't imagine why anyone would want them on, even on a development server. When I use a local variable, I expect the scope to remain local. I don't want variable scopes bleeding into each other.