On 8/13/16 9:02 PM, Yasuo Ohgaki wrote:
Hi Tom,
On Sun, Aug 14, 2016 at 12:35 AM, Tom Worster <f...@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
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
