Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95200
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.115 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXaZhfXbU6N0-JGVPzkkxRdkcjEhkHP+YrQNH=XFX714-Q@mail.gmail.com>
 <72327660-e601-6c75-c14d-41785cf1ce5f@thefsb.org>
 <CAGa2bXaVUXPvH2CSgvZwpwRtSMc+2mQUVoiomwYb30evQKBifw@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <9065fe5b-43b2-9ab1-9197-f6d05243f050@thefsb.org>
Date: Mon, 15 Aug 2016 13:36:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaVUXPvH2CSgvZwpwRtSMc+2mQUVoiomwYb30evQKBifw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC][VOTE] Add session_create_id() function
From: fsb@thefsb.org (Tom Worster)

On 8/13/16 9:02 PM, Yasuo Ohgaki wrote:
> Hi Tom,
>
> On Sun, Aug 14, 2016 at 12:35 AM, Tom Worster <fsb@thefsb.org> wrote:
>> Rather than argue the details of randomness, I have more basic comments.
>>
>> 1. If an app needs to access session values, it can and should do this
>> without indirection through the PHP session ID table.
>
> I don't get point. Why?

1) It is not necessary. An app can instead store session-related data in 
a DB that provides lookup and/or search on the session data itself 
rather than the PHP session key. Lester Caine described this.

2) Searching PHP's session database is nasty. It's low-level and the app 
has to understand the handler. But I want apps to work independent of 
sessions being in memcache to Redis or Galera or whatever. Depending on 
handler, it can involve a scan which is slow. And it's hard to make the 
overall operation that uses session table lookup transnational. And the 
session store may be distributed example below(*).

So it's nasty **and** unnecessary. Instead, the app can and should 
implement the business logic to be entirely above and ignorant of PHP 
session mechanics.


>> 2. Users should generally let PHP choose random IDs.
>
> I agree.
>
>>
>> 3. If PHP is to allow a user to chose its own session IDs, avoiding
>> collision is should that user's responsibility.
>
> No. I've already explained why this is difficult.

It is easy if you choose to **avoid** rather than **detect**. Use a 
random component long enough for your needs. In other words, I disagree 
with the sentence in your RFC:

 > Something like above code is required to implement recommended user 
session save handlers currently.

It is not needed because if 64^32 SID values is inadequate for your app 
then you may increase session.sid_length.


> Please read previous mail.
> Or try to write session save handler that detects collisions with
> memcached, then you'll see why.

I understand your point. At the same time I see no need for collision 
detection.

Questions: When I get a value from session_create_id(), what kind of 
guarantee comes with it? Is the ID reserved for me? If so, for how long?


>> 4. Generating unique unpredictable IDs (without requiring collision
>> detection) is a common problem with known and trusted solutions.
>
> I agree. It's common because many unique ID generator do not have
> centralized database to avoid collisions. In contract, session has
> centralized database and it's just a matter of one lookup. (Therefore,
> session module should lookup database)

(*)Some session stores are federated, e.g. a cluster of 3 hosts each 
with a memcached server and each with PHP configured with session 
redundancy to save two copies.

While session_create_id() could potentially use the same hashes that 
memcache/d extensions uses to associate SIDs with memcached servers, the 
app has to search them to find the entry with a given SID prefix.


> Regards,
>
> P.S. I'll add optimization that eliminates SID validation lookup for
> normal operations. You don't have to worry about session performance
> if I add this.
>
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>