| Re: Completely stumped (still) [message #185069 is a reply to message #185066] |
Tue, 25 February 2014 19:28   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
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.
> 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).
>> 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.
>> 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.
>> 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
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]