Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89861
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CALrkBjaWRc-1=HKZOm3gOuRSNyjUuW94PdYDOdOg1sQOOqXXgg@mail.gmail.com>
References: <CAGa2bXbg_kebBVg3tSh4uFHZ6nQXRbjUXNQa0JZx9sezQqb5kg@mail.gmail.com>
 <CAGa2bXaiqHvAxW4OdcAWfGk2KpMW9ZmZsODSK7W2p4j6_FL79w@mail.gmail.com> <CALrkBjaWRc-1=HKZOm3gOuRSNyjUuW94PdYDOdOg1sQOOqXXgg@mail.gmail.com>
Date: Tue, 22 Dec 2015 14:37:12 +0900
Message-ID: <CAGa2bXbJTjwdgL++o75tWir=HbCeioBVtyFyauD0et8CEjmnLg@mail.gmail.com>
To: Mike Willbanks <pencap@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC Discussion] Precise Session Management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Mike,

On Mon, Dec 21, 2015 at 1:24 PM, Mike Willbanks <pencap@gmail.com> wrote:
>
> On Sun, Dec 20, 2015 at 7:01 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> Hi all,
>>
>> On Sat, Dec 19, 2015 at 7:33 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> > I would like to restart better session management for PHP 7.1.
>> >
>> > https://wiki.php.net/rfc/precise_session_management
>> >
>> > Although this RFC targets PHP 7.1, new session management
>> > could be applied to older releases also if majority of us agree.
>> > Please comment.
>>
>> I would like to write patch for this next week.
>> If you have comment, please comment this week.
>
>
> This week is hard due to several holidays, I would recommend postponing
> discussion until after.

Thanks.
I'm working on this for years. I'm not in hurry.

>
>
> However, I will comment on a few things that I dislike of the RFC:
>
> Exposing the internal state of the session via a key on the session
> __SESSION_INTERNAL__ may be dangerous.  How are you preventing writes to
> this area?  Is an exception or error thrown?  I also do not feel that it is

The session internal data structure (__SESSION_INTERNAL__) is removed when
the data is unserialized. It is added back when session data is serialized. So
user cannot see/touch private session data at all.

If user add $_SESSION['__SESSION_INTERNAL__'] in user script, the module
remove it and raise E_WARNING.

> worth encoding this directly into the session value but would be of far
> greater benefit to expose through functions and ensure it is not touched and
> protected from user land.  Anything that messes with the $_SESSION can cause
> major issues (for instance upload progress did this and can cause session
> corruption in certain cases as it manipulates the session state).

Please file a bug report for this.

As I wrote in previously, $_SESSION['__SESSION_INTERNAL__'] is completely
hidden and untouchable from users

> I fully agree that session_regenerate_id needs some additional work.
> Although. I do not think that the implementation here seems like the correct
> path as a general comment.

From user point of view, $_SESSION['__SESSION_INTERNAL__'] is a new reserved/
restricted session key.

We had such restriction before "php_serialize" serialize option. e.g.
$_SESSION['1'] ,
$_SESSION['1abc'], etc are invalid keys and raises confusing error messages. Key
name must be valid as variable name for serialization method other
than "php_serialize".

I could choose to use completely new session serialization method like

$__PSEUDO_SESSION_DATA__ = $SESSION_INTERNAL_DATA[] + $_SESSION[]
where $SESSION_INTERNAL_DATA is $_SESSION['__SESSION_INTERNAL__'] and
$_SESSION is the current session data array.

No reserved key is required with this. However, this method breaks
almost all 3rd party
session data management libraries that access session data storage directly.
Therefore, I chose to add and hide session internal data structure in $_SESSION.
However, this could be vote option.

Thank you for your comment!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net