Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85171
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXb2qm3Y0S_dVDe+Orh6kbuuQOOgLNc_VwycZCCiSxPZ2w@mail.gmail.com>
References: <CAGa2bXb2qm3Y0S_dVDe+Orh6kbuuQOOgLNc_VwycZCCiSxPZ2w@mail.gmail.com>
Date: Wed, 18 Mar 2015 17:57:22 +0900
Message-ID: <CAGa2bXauT9Kq74FDqq+0gyGUUa5FRirkryRHtBVei5hLJHbVUw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1142eb76e1145f05118c472d
Subject: Re: Bug #69127 session_regenerate_id(true) randomly generates a
 warning and loses session data
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1142eb76e1145f05118c472d
Content-Type: text/plain; charset=UTF-8

Hi all,

On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> https://bugs.php.net/bug.php?id=69127
>
> This bug is known fatal bug for session module. I proposed "lazy_destroy"
> to fix
> this before, but it declined.
>
> I think the name was wrong. With the proposal, session module destories
> session data with lazy manner, but it's actually precise manner. i.e.
> Session
> module and browser is _not_ synced, so destroy must be done async manner
> (~= lazy manner. For example, delete session data 60 seconds later).
>
> The reason why session_regenerate_id(true) fails is it deletes session
> data
> immediately even if session and browser is not in sync. Session and
> browser
> cannot sync because there is no means in HTTP/Cookie.
>
> Is there any other better idea for this?
>

I would like to fix this bug transparently. i.e. User cannot detect already
destroyed
session that is accessible.

The method is:

1. Add "__SESSION_TTL__", which has TTL timestamp, to $_SESSION hash before
serialization.
2. If session module finds "__SESSION_TTL__" in unserialized data and TTL
is past, then
regenerate session ID and create new session with empty data. (Old session
data is deleted actually)
3. If session is accessible by step 2, store TTL to PS(ttl) and initialize
$_SESSION without "__SESSION_TTL__".
4. If PS(ttl) has value greater than 0, add PS(ttl) back to session data
before serialization.

Note: Serialization/unserialization is done in session module. User cannot
know the existence.


I don't think users are using "__SESSION_TTL__" key for $_SESSION, but it
is possible.
If there is invalid "__SESSION_TTL__" in $_SESSION, raise E_NOTICE and
remove the key from
$_SESSION.

BC happens only when "__SESSION_TTL__" is used by users.

I would like to fix this in released versions, but it requires addition to
session module globals.
Fix will be only available to PHP7.

However, PS(ttl) can be added to the end of PS(). If this is OK, I'll fix
this bug from PHP 5.4.

Comments are appreciated.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1142eb76e1145f05118c472d--