Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85342
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXZjXGQvb+h+ygB2A-KK1Zg=jvoiu0Oq1C6nOH37=bL+SQ@mail.gmail.com>
References: <CAGa2bXb2qm3Y0S_dVDe+Orh6kbuuQOOgLNc_VwycZCCiSxPZ2w@mail.gmail.com>
 <CAGa2bXauT9Kq74FDqq+0gyGUUa5FRirkryRHtBVei5hLJHbVUw@mail.gmail.com>
 <20150320101241.GA69273@mail.digitalsun.pl> <CAGa2bXZjXGQvb+h+ygB2A-KK1Zg=jvoiu0Oq1C6nOH37=bL+SQ@mail.gmail.com>
Date: Sat, 21 Mar 2015 06:49:43 +0900
Message-ID: <CAGa2bXbN33uEt4FjZ40_JX8dzR=+jbqA10W4qFc=ECL04uE7_Q@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01537e76be944f0511bf4df2
Subject: Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly
 generates a warning and loses session data
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01537e76be944f0511bf4df2
Content-Type: text/plain; charset=UTF-8

Hi all,

On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski <shm@digitalsun.pl>
> wrote:
>
>> Doh, it's happening again, it was discussed before. Anyway, your solution
>> seems to not fix the real problem behind the bug entry. I suspect that
>> following scenario may occur:
>>
>
> Of course it was. I remember well.
> Discussion was not going well because people does not understand
> nature of web session. i.e. Session management is asynchronous.
>
> It works almost always under stable network, but it cannot with unstable
> network.
>
>
>>
>>  http://lxr.php.net/xref/PHP_5_4/ext/session/mod_files.c#429
>>
>>  scenario could be as follows:
>>
>>  1. request A is done with sessid=123
>>  2. A calls session_regenerate_id and is preempted after unlink(2) but
>> before
>>     access(2)
>>  3. request B is done with sessid=123 - session_start creates the session
>>  4. request A wakes up, session is written to fs by request B, so destroy
>>     fails
>>
>>  Please note that if destroy fails, then new session is not generated,
>> possible (but ugly) solution is to call session_regenerate_id again.
>>
>
> It just does not work.
> How do you keep session for lost session?
>
> Lost session occurs like
>
> 1. Server executes session_regenerate_id(true), delete old data and send
>     new session ID with copied data to browser.
> 2. Unstable network lost packet that sets new session ID.
> 3. Browser thinks old session ID is valid, but there is no session data
> for it.
>
> Besides, there is issue that session data must be deleted may keep alive
> forever. Current session management is not predictable and precise at all.
>
> If there is better idea other than the RFC, I appreciate it.
>

BTW, if there are users who do not care about mobile devices at all, they
can simply set session.destroy_ttl=0.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01537e76be944f0511bf4df2--