| Re: Completely stumped (still) [message #185076 is a reply to message #185069] |
Tue, 25 February 2014 21:04   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 2/25/2014 2:28 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 2/25/2014 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Christoph Michael Becker wrote:
>>>> >> Richard Yates wrote:
>>>> >>> But I don't understand how setting the variable: $to can affect the
>>>> >>> array: $_SESSION['to']? They are completely different variables.
>>>> >>> And why would it all work fine on other servers?
>>>> >>
>>>> >> Frankly, I don't know. If I had to examine the issue, I'd probably
>>>> >> check the value of $to at the start of the script execution and
>>>> >> directly after the session start. If $to is set in either case, that
>>>> >> would give a hint. If $to is null at the start of the script
>>>> >> execution, but is set to the value of $_SESSION['to'] after starting
>>>> >> the session, checking the session handler would be appropriate. And
>>>> >> if $to is already set at the beginning of the script execution,
>>>> >> checking the register_globals setting[1] seems appropriate (even if
>>>> >> that wouldn't explain the strange behavior per se).
>>>> >
>>>> > session_register('to');
>>>> >
>>>> > <http://php.net/session_register> (deprecated since 5.3, removed in
>>>> > 5.4) would explain it even if
>>>> >
>>>> > $to =& $_SESSION['to'];
>>>> >
>>>> > was missing.
>>>>
>>>> If that were the case, it would fail on all his systems. Note he is
>>>> running the same code on 4 different systems, but it only fails on one.
>>>
>>> There are too many unknowns here to be certain. There could be
>>> conditionally executed statements. There could be auto_prepend_file.
>>> There could be extensions interfering. And so on.
>>
>> No, there are no unknowns.
>
> Yes, there are.
>
Then why did he indicate my answer was correct?
>> He has a script which works one way on three systems and another way on a
>> fourth system. The script is not the problem.
>
> Please get informed about conditional statements, auto_prepend_file, and the
> other possibilities I mentioned (and not mentioned).
>
I am familiar with them. They are not pertinent to the problem at hand.
>>> However, I am willing to concede to you that “register_globals = on”,
>>> which you suggested elsewhere, is the Occam’s-razor-explanation here.
>>
>> It is pretty much the ONLY solution here. The solution is NOT a
>> differences in scripts.
>
> You just couldn't leave it at that. You had to be "right" in the end.
>
Nope, you're just pissed off because someone else knew the answer and
you didn't.
>>> Never having relied on it, I was not aware that this directive would
>>> affect $_SESSION as well, and that session_register() does not work with
>>> “register_globals = off” (which explains why that function was removed as
>>> of PHP 5.4 as well, see bottom):
>>>
>>> ,--[ibid.]
>>> |
>>> | Caution
>>> | If you want your script to work regardless of register_globals, you
>>> | need to instead use the $_SESSION array as $_SESSION entries are
>>> | automatically registered. If your script uses session_register(), it
>>> | will not work in environments where the PHP directive register_globals
>>> | is disabled.
>>>
>>> If “register_globals” is the culprit, it has to be "on" on this one
>>> system which must run PHP 5.3 or earlier; either it has to be "off" on
>>> the other three systems, or they must run PHP 5.4 or newer (where the
>>> directive is no longer supported), respectively.
>>
>> That is exactly the case.
>
> You do not know that for certain. Claiming that you do does not make it so.
>
Yes, I do. The OP acknowledged it.
>>> The OP should call phpinfo() to check the used PHP version and the actual
>>> value of the setting; they should check the .htaccess, and .config files
>>> in that directory and up to the document root, the virtual host
>>> configuration (if any; unfortunately, the aforementioned files are not
>>> listed by phpinfo()), and the configuration files listed by phpinfo(),
>>> for the directive.
>>>
>>> And they should stop writing/using PHP programs that require the setting
>>> to be "on" now, before they are forced to by PHP < 5.4 becoming
>>> unavailable.
>>
>> That has been the case ever since PHP 4.2.
>
> (Your statement does not make sense.)
>
> The *built-in* *default* for “register_globals” is "off" since PHP 4.2.
> Many people have set it to "on" without knowing it. Some have it set to
> "on" deliberately, many of them are unaware of the full consequences, few
> accepted them willingly.
>
> <http://php.net/manual/en/ini.core.php#ini.register-globals>
> <http://php.net/manual/en/security.globals.php>
>
>
> PointedEars
>
It makes perfect sense if you understand English.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]