Re: [RFC][VOTE] Add session_create_id() function

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