Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CA+kxMuR=JQugpLhG2ghGtAbwO=JBvKsAaFU2AqNRw++3unJ9MQ@mail.gmail.com>
References: <CAGa2bXbg_kebBVg3tSh4uFHZ6nQXRbjUXNQa0JZx9sezQqb5kg@mail.gmail.com>
 <CAGa2bXYZXkCJwFKVwaNfV+OEw0FzeFFbtxLm0zRmFVE_b4xsMw@mail.gmail.com>
 <CAGa2bXbRJMZFcXfZc9o7YnAhkDRfYKPjO+10k-eKXdoGNTREbg@mail.gmail.com>
 <CAGa2bXYGpV=P-680ig1LOkYWsSRS-Ya2rYVa3wo3vrxdT=zwiw@mail.gmail.com>
 <56A727C3.9070505@gmail.com> <CAGa2bXYj6iCvKqcpf_p6Dm_TNOxtVozry=AONKWu9-VKzb_FHw@mail.gmail.com>
 <CAGa2bXZ3gFegniSBCtfnnrrotbdCh+MjGufC11nYhd7kH31tuQ@mail.gmail.com> <CA+kxMuR=JQugpLhG2ghGtAbwO=JBvKsAaFU2AqNRw++3unJ9MQ@mail.gmail.com>
Date: Wed, 27 Jan 2016 07:14:59 +0900
Message-ID: <CAGa2bXa=pJ_J-Gy7gEuyywJ7asc78cR4w3Nkn65Ek1tE7DtJHw@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"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 Dan,

On Wed, Jan 27, 2016 at 12:05 AM, Dan Ackroyd <danack@basereality.com> wrote:
>> I'll appreciate if one could find defect if there is.
>
> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.
>
> Or to put it more colloquially this is a "how to get to Dublin
> problem". To get to having a more secure and reliable session
> handling, we need to start from some where else, not just keep
> building on top of the current session handler code.
>
> The proposed RFC is not a good way to proceed. Having functionality
> depend on setting values in an array like this (as far a I've
> undertood the RFC):

Why depending setting values (timestamp) is not good way.
If you know, please let me know how to manage expiration w/o timestamp.

>
> // Resend new session ID once. This will reduce chance of client
> // race and lost session by unstable network to acceptable level.
> $_SESSION['__PHP_SESSION__']['NEW_SID_SENT'] = time();
>
> is not a sensible way of programming imo. Additionally, changing code
> that is apparently very fragile and so breaking people's applications
> in subtle ways, is not something we should be doing.

I agree that it is difficult for people who don't know PHP session
module code. Function dependency and state management may
seem like maze. However, once you understand, it's not that hard.
It's only a few thousands lines.

>
>> Anyway, we may be better to talk about how it should be.
>> For this thread, how session management should be.
>> It's just not good enough currently.
>
> To me, there are two good ways to proceed:
>
> i) Develop a new session extension, that doesn't depend on magic
> behaviour of globals and leave the current session handler as it is.
> The new session extension could be shipped as a 'work in progres' when
> it's good enough, before PHP 8. Then when it's stable, we could figure
> out how to transition users from the old extension.
>
> ii) Develop a session handler in userland code only. PHP is powerful
> enough to support this. Although obviously there are big benefits to
> shipping a session handler with PHP, I don't see any need for it to be
> done internally other than we don't currently have a way of shipping
> userland code with an extension. I'm hoping that before PHP 8, the
> ability to ship PHP code as part of extensions would be in place.
>
> Either of those two would be feasible. The proposed RFC doesn't appear
> feasible to me.
>

Why? it's already there and it works.
You are proposing

 - Leave random lost session bug
 - Leave session exploit easy

I think we must fix these.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net