Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90337
Return-Path: <yohgaki@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 78827 invoked from network); 8 Jan 2016 01:29:17 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 8 Jan 2016 01:29:17 -0000
Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
X-PHP-List-Original-Sender: yohgaki@gmail.com
X-Host-Fingerprint: 209.85.160.170 mail-yk0-f170.google.com  
Received: from [209.85.160.170] ([209.85.160.170:36665] helo=mail-yk0-f170.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id C7/94-55593-AE01F865 for <internals@lists.php.net>; Thu, 07 Jan 2016 20:29:14 -0500
Received: by mail-yk0-f170.google.com with SMTP id v14so254093466ykd.3
        for <internals@lists.php.net>; Thu, 07 Jan 2016 17:29:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        bh=se37Fr6iBMaundhMx+d2ShX3gb4RYXKZ4gSfhV/hJlc=;
        b=a5G8ILb25UuLwgrZzqAyePJN4XLG9ryJFriJPepYQ2KTyINhiBxObnvCj+3ll4MQjx
         /xsF4G3aRFEfwPzwZnIVwj3cd/Wsj9fmI6GybeARMt5kFB5rKVfczRmjYmTV8YGNTkIm
         0dDH1ZiRz40MOPNjy+xP6Aov/rmfNSLdbxaVvrJTOcr5rpzneSTTsOSnzsLUxCB+Cq1X
         CjspwoZo6X0Wi12TrXo4pPLLwR7STdd3gePBFLV4RKrQkVKC+kC6VC8HCcxuU+OmO1nK
         GB4F1BFRiVsjN7xRgh93eZW+xgmQSBWtDZN2x7ZiVGDr0Jj6cjBkiFXA6URpwdgU31LP
         JSQw==
X-Received: by 10.129.128.198 with SMTP id q189mr2269611ywf.220.1452216550805;
 Thu, 07 Jan 2016 17:29:10 -0800 (PST)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
Received: by 10.129.88.139 with HTTP; Thu, 7 Jan 2016 17:28:31 -0800 (PST)
In-Reply-To: <CA+kxMuTuZ7ThA1R-OVV0O=jEQ0u8Ka5jjWdwY8OB-zQpBHL1XA@mail.gmail.com>
References: <CAGa2bXbg_kebBVg3tSh4uFHZ6nQXRbjUXNQa0JZx9sezQqb5kg@mail.gmail.com>
 <CAGa2bXbWgdnmz2g4OWCxLb=TdeqyiajNm9Q7HX96FKQq8tqqtw@mail.gmail.com> <CA+kxMuTuZ7ThA1R-OVV0O=jEQ0u8Ka5jjWdwY8OB-zQpBHL1XA@mail.gmail.com>
Date: Fri, 8 Jan 2016 10:28:31 +0900
X-Google-Sender-Auth: cafNMG8dpxWw17U6SzEZnpRPuz4
Message-ID: <CAGa2bXb3W4DN24OCR=f5z7YfQTrHHM6q9Ai8ROZoHF4+pHEZkg@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: "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 Fri, Jan 8, 2016 at 12:54 AM, Dan Ackroyd <danack@basereality.com> wrote:
>
> I find it hard to give feedback on this RFC as I cannot understand
> what it is saying.
>
> In an RFC, defining behaviour just through example like this:
>
>> Obsolete session data has NEW_SID and TTL upto session.ttl_destroy.
>>
>>   $_SESSION['__PHP_SESSION__']['NEW_SID'] = <new session ID>;
>>   $_SESSION['__PHP_SESSION__']['TTL'] = time() + ini_get('session.ttl_destroy');
>
> doesn't communicate clearly what the behaviour is going to be. There
> needs to be a clear description of what is going to happen.


$_SESSION['__PHP_SESSION__']['NEW_SID'] = <new session ID>;

This is used to re-send new session ID as follows

 if (isset($_SESSION['__PHP_SESSION__']['NEW_SID'])) {
    // Must not update obsolete session TTL.
    if ($_SESSION['__PHP_SESSION__']['TTL'] - time() < -60
        && !isset($_SESSION['__PHP_SESSION__']['NEW_SID_SENT']) {
      // 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();
    }

In English, it checks obsolete session by
$_SESSION['__PHP_SESSION__']['NEW_SID']
and if it is older than 60 seconds, re-send new session ID once. The
reason why this
is mandatory is described in the RFC.

$_SESSION['__PHP_SESSION__']['TTL'] = time() + ini_get('session.ttl_destroy');

This is simply TTL (Tive To Live) for the session.


> The only feedback I can give is that I think complex session behaviour
> need to be managed through objects or functions which can be tested
> inside an application. Adding complex behaviour that happens just when
> certain elements of a global array is set, is not the right way to add
> more complexity to the session management.

It may sound complex, but what is does is simple and decent session
manager should have. The objectives are

 - Make sure old/obsolete session is deleted within certain period.
  (Currently, it does not)
 - Make sure session manager will not lost outstanding session.

It should be basic session manager task, IMHO.

Random lost session and use of obsolete session is unacceptable.
Detecting lost session by unit test is impossible also.

>
> My personal belief is that if people want to have more complex session
> management, they should do so in userland code. If we do want more
> advanced session in core, it should be done as a new extension; one
> that doesn't use any ini settings at all...

PHP should be able to build secure/reliable web apps quick and easy.
I don't think many of PHP users know/understand details of precise
session management. It's better to provide precise session manager
out of the box.

>
> btw this appears to be a list of the RFCs you currently have open.
>
> https://wiki.php.net/rfc/allow_url_include
> https://wiki.php.net/rfc/consistent-names
> https://wiki.php.net/rfc/consistent_function_names
> https://wiki.php.net/rfc/dbc2
> https://wiki.php.net/rfc/deprecate_ini_set_get_aliases
> https://wiki.php.net/rfc/escaper
> https://wiki.php.net/rfc/introduce_design_by_contract
> https://wiki.php.net/rfc/inconsistent-behaviors
> https://wiki.php.net/rfc/introduce-type-affinity
> https://wiki.php.net/rfc/precise_float_value
> https://wiki.php.net/rfc/script_only_include
> https://wiki.php.net/rfc/secure-session-options-by-default
> https://wiki.php.net/rfc/session-gc
>
> Perhaps spending more time polishing one or two ideas would lead to a
> better result than spreading your efforts thinly across many ideas?

I was proposing this idea over years in fact.
Only relevant RFC is session-gc which I included it into this RFC. This RFC
was part of old declined RFC and I think I polished the idea  generic enough.
e.g. Extendable to implement automatic CSRF protection.

Anyway, I don't believe all of PHP users can do the same session management
even if it could be done in user script. Few people were suggested the same, it
should/could be done in userland, for the old RFC, too. How many web
apps/frameworks are adopted the suggested session management since the
last declined RFC?

https://wiki.php.net/rfc/session-lock-ini#proposal_4_-_lazy_destroy

There weren't many. Therefore, providing it out of the box is worth the effort.

Regards,

P.S. Priority of strict_session RFC
https://wiki.php.net/rfc/strict_sessions
was a lot higher than this RFC as loose(adoptive) session manager allows
to steal session _permanently_. Since it's implemented, this RFC became
1st priority for me. This RFC enables session.use_strict_mode by default
also.

--
Yasuo Ohgaki
yohgaki@ohgaki.net