Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95138
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <592333a7-2c73-38a4-b400-f3f2c7bf2f72@lsces.co.uk>
References: <CAGa2bXaZhfXbU6N0-JGVPzkkxRdkcjEhkHP+YrQNH=XFX714-Q@mail.gmail.com>
 <CAPwsocFAMofROQE-OBfNiR4yrKKSss_owu0svu+Db66DmRbShw@mail.gmail.com>
 <CAGa2bXaxRA91q+ev-X3okKpNC=s3XEwC9deUYikTaUQPfOE-JQ@mail.gmail.com>
 <cc719c6c-598d-b103-96bf-eb3714a61365@thefsb.org> <CAGa2bXYNExeQLug=co8G1g+fdy6BXK9UbeyGkjss5s62R00Fdg@mail.gmail.com>
 <D3D49F41.70F4A%fsb@thefsb.org> <CAGa2bXYa-6gpyUH_yXwoob8aZA_UVjuRfzbrMxfdUp7j5jk8EQ@mail.gmail.com>
 <592333a7-2c73-38a4-b400-f3f2c7bf2f72@lsces.co.uk>
Date: Sun, 14 Aug 2016 21:33:55 +0900
Message-ID: <CAGa2bXYuO+y155BHG1hZSO75TzZqkH1RyU6C6jigEo9_goJoBA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Lester,

On Sun, Aug 14, 2016 at 5:35 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 14/08/16 01:56, Yasuo Ohgaki wrote:
>> IMO. PHP should be easiest, yet secure, Web application programming language.
>> I don't see any benefits, but only drawbacks, forcing users "to know session
>> management details to write secure code" while it is very easy to implement
>> tham in Session module.
>
> Sessions are something I rely on, but have thrown numerous problems over
> the years. In my systems they should exist for the duration of a client
> being logged into the system and so any problems either end have to be
> handled. For that reason I store them in the database so when a client
> has to log in again we can clear their last activity and start a new
> one. The clients can be carrying out interviews for an hour or more, so
> previous 'improvements' that try to clear 'inactive sessions' often lost
> MY sort of sessions. Clients are only allowed to log on once so I need
> to pick up if they try and start a second session, but I don't believe I
> NEED all the complexity of cryptography secure id's? Just ones where I
> CAN actually identify the client ... or should I be handling that
> separate from the actual session_id ?

Concept of Session is simple just like transaction. Concept of transaction is
simple but implementation requires complexity to do the job right.

You wouldn't say 'Transaction could be inconsistent under rare unfortunate
situations' probably.

Anyway, session module generates collision free session ID by default. Why
not for API generates new ID? Collision check for new session ID is cheap
because it does not happen for every request, but only when session ID
is regenerated.  In addition, user needs a lot of work and details of
session, including session save handler knowledge to generate collision
free session ID.

If anyone would really like to remove collision check overhead, they should
do it by themselves. Unlike collision free session ID generation, it's very
easy. Users can do

ini_set('session.use_strict_mode', 0);
session_id('my_session_id');
session_start();

with their own responsibility and risk.

Regards,

P.S. The next step having session_create_id() is session_regenerate_id()
change. For example, having user ID prefixed session would be just

session_regenerate_id(session_create_id($userid));

Warning: To do things like this safely, user MUST enable use_strict_mode!!

--
Yasuo Ohgaki
yohgaki@ohgaki.net