Re: Session variable not persisting
| From: | Éric Oliver Paquette | Date: | Mon, 18 Mar 2013 20:14:32 +0000 |
| Subject: | Re: Session variable not persisting | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.general php.general |
| Request: | Send a blank email to php-general+get-320644@lists.php.net to get a copy of this message | ||
Le 2013-03-18 à 15:41, Éric Oliver Paquette a écrit :
>
> Le 2013-03-18 à 15:37, Matijn Woudt a écrit :
>
>>
>>
>>
>> On Mon, Mar 18, 2013 at 8:35 PM, Éric Oliver Paquette <eopaquette@gmail.com> wrote:
>>
>> Le 2013-03-18 à 15:24, Éric Oliver Paquette a écrit :
>>
>>>
>>> Le 2013-03-18 à 15:20, Matijn Woudt a écrit :
>>>
>>>>
>>>>
>>>>
>>>> On Mon, Mar 18, 2013 at 8:13 PM, Éric Oliver Paquette <eopaquette@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Mon, Mar 18, 2013 at 7:46 PM, Éric Oliver Paquette
>>>>> <eopaquette@gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> I'll be swift in my explanation as I can't find in any way the source
>>>>> of the problem; it seems to be installation-related.
>>>>>
>>>>> At execution, sometimes (randomly it seems at first), variable session
>>>>> aren't properly stored.
>>>>>
>>>>>
>>>>> In fact, when I run this on my server I randomly have empty entries in the
>>>>> $_SESSION array. Any thoughts on this? Is this a known bug (haven't found it…)
>>>>>
>>>>> Thanks!
>>>>>
>>>>> What does phpinfo() show about session stuff? Especially things like
>>>>> save_handler and cookie_lifetime settings.
>>>>
>>>> Note that this seems to occur 3 times out of 1000 on average.
>>>>
>>>> Now, about your request :
>>>>
>>>> session
>>>>
>>>> Session Support enabled
>>>> Registered save handlers files user
>>>> Registered serializer handlers php php_binary wddx
>>>>
>>>> Directive Local Value Master Value
>>>> session.auto_start Off Off
>>>> session.bug_compat_42 Off Off
>>>> session.bug_compat_warn Off Off
>>>> session.cache_expire 180 180
>>>> session.cache_limiter nocache nocache
>>>> session.cookie_domain no value no value
>>>> session.cookie_httponly Off Off
>>>> session.cookie_lifetime 0 0
>>>> session.cookie_path / /
>>>> session.cookie_secure Off Off
>>>> session.entropy_file no value no value
>>>> session.entropy_length 0 0
>>>> session.gc_divisor 1000 1000
>>>> session.gc_maxlifetime 1440 1440
>>>> session.gc_probability 1 1
>>>> session.hash_bits_per_character 5 5
>>>> session.hash_function 0 0
>>>> session.name PHPSESSID PHPSESSID
>>>> session.referer_check no value no value
>>>> session.save_handler files files
>>>> session.save_path /var/lib/php/session /var/lib/php/session
>>>> session.serialize_handler php php
>>>> session.use_cookies On On
>>>> session.use_only_cookies On On
>>>> session.use_trans_sid 0 0
>>>>
>>>>
>>>> Your settings seem to be fine. My best guess would be hardware failure, though it
>>>> seems unlikely. Did you check apache (or whatever webserver you're using) logs for any errors
>>>> or warnings?
>>>
>>> Yes I did. Everyhting seems normal there too.
>>
>> Hm… Just noticed something new in fact; was looking a last time before considering
>> reinstallation on a new server: it seems that the $_GET['push'] is undefined. In the other
>> scripts I use where I have this problem, I'm using $_POST variables though but still don't
>> get stored in $_SESSION. If I'm correct, this may implies that it is apache that is faulty
>> right?
>>
>>
>>
>> $_GET['push'] will be undefined if you still have your session stored, but
>> accessing the script directly. It should have nothing to do with faulty Apache.
>
> Okay, let me paraphrase: when I run the ping pong scripts written up there, I have a blank in
> var_dump($_SESSION) if and only if I have
>
> [Mon Mar 18 13:25:37 2013] [error] [client 184.151.114.111] PHP Notice: Undefined index: push
> in /home/www/www.ngenioconnect.com/Modules/MPOSurveyTest/pong.php on line 8
>
> on apache log. So my question really is, it is apache that handles the posts and gets requests,
> as I use both and it seems that the non-persistence of data occurs before the storage in $_SESSION,
> is it possible that it is Apache that is faulty?
Er… I looked where it caused a problem, it seems that $_GET, $_POST and $_SESSION are indeed all
affected. Any clue of a faulty installation that would cause problem for many surperglobals?