Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 74.125.82.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa0tn2OODr4kVC_FYtkpXsR6jGwc4172dq3WSRCdpkAzw@mail.gmail.com>
References: <CAGa2bXa0tn2OODr4kVC_FYtkpXsR6jGwc4172dq3WSRCdpkAzw@mail.gmail.com>
Date: Wed, 8 Jan 2014 16:17:16 +0000
Message-ID: <CA+kxMuTtq25Uzj=NOfa4vAkfXzxcDDA7fUvSO8OOJqEBrsuSkQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Introduce session.lock, session.lazy_write and session.lazy_destory
From: danack@basereality.com (Dan Ackroyd)

Hi,

While I agree with the rationale for wanting more advanced behaviour
from the session management functionality in PHP, I don't think adding
more functionality to the built in session_* functions will give a
result that is satisfactory.

The problem is that most of the information about how the sessions
should be managed lives at the application level. It will also vary
within an application depending on what the user is doing. Some
examples, from the RFC:

Session locking - If an application knows that it won't be writing any
data to the session, it should be able to read the session data
without ever locking the session data.

There are also session write operations that just don't need any
locking at all. For example if you want to just record the number of
pages a user has viewed since they logged in:

  $_SESSION['pagesViewed']++;

With a Redis storage backend for the session data, this can be done
without any locking at all, if the application is written without
assuming that the session data will be locked.

Race condition around regenerated session IDs - The proposal to allow
clients that try to use a session ID that has recently been
regenerated would not be acceptable for all clients. Some clients
would probably prefer to send a HTTP error code (419 Authentication
Timeout?) indicating that the client should resend the request with
the new session ID.

It's also likely that applications would want to allow recently
regenerated session IDs to be allowed for read operations, but not for
write operations.


The previous discussions about improving security for sessions are
another example of where the logic isn't simple and what exactly
happens when the client changes either I.P. address or useragent
during a session is totally dependent on the application.

i.e. for a banking application, if the user ever changes IP address,
then it would be acceptable to instantly terminate that session.

For a shopping application, if the user changes IP address to one that
is within a close geographical aread as the original IP address, then
the application could let that session continue, and only terminate
the session if the new IP address appeared to be physically far away
from the original IP adress.

Also there are already 26 ini settings for handling the sessions in
PHP (ignoring the ini settings related to tracking upload progress).
This a pretty clear indication that the handling of sessions is
already too complex to be controlled through ini settings alone.

At the risk of setting myself up for a fall, I'm going to make a proof
of concept userland session manager to try and implement as many of
the features under discussion in the various session related RFCs that
are open as possible, and will try to publish it in a week or so. It
probably won't be anywhere near production ready, but hopefully will
provide a basis for discussing moving the session handling from the
session_* functions to something that allows people to define the
logic in code, rather than being forced to tweak a huge number of
config settings.

cheers
Dan

On Sat, Dec 21, 2013 at 10:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi all,
>
> This was discussed before.
> I've created RFC for more discussion.
>
> https://wiki.php.net/rfc/session-lock-ini
>
> Please comment if any.
>
> Thank you.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net