Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71293
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52DC905F.2080705@sugarcrm.com>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
 <52DC905F.2080705@sugarcrm.com>
Date: Mon, 20 Jan 2014 13:27:03 +0900
Message-ID: <CAGa2bXbrr3CreZoaasDFWebSG-f4ai-AcTEiX9BGXZLTvjjb+Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c25dea26e72604f05f50f7
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c25dea26e72604f05f50f7
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Mon, Jan 20, 2014 at 11:56 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > Vote period: 2014/01/20 - 2014/01/30
> > https://wiki.php.net/rfc/session-lock-ini
> >
> > New comments and questions are welcomed.
>
> I see there are three proposals there, but only one vote. E.g. I think
> unlocked sessions are not a good idea, but lazy write may be ok (btw,
> interaction between no-lock and lazy write can lead to completely
> undebuggable scenarios when same data by same code sometimes are written
> and sometimes are not depending on session state).


It is made a single RFC so that everyone understand new features.

I agree that unlocked session could be a cause of hard to debug bugs and
it should never be a default.

Even if unlocked session can be dangerous, there are save handlers
that support unlocked session for better performance. e.g. memcache. It
would
be reasonable to support by module.

Unlocked session could be more usable by session.lazy_write. According to
current
implementation, "the last session wins". With session.lazy_write, "the last
session
*writes data* wins". This behavior prevents loosing updated data. It's
better for
performance also.


> I'm not sure I even
> understand what lazy_destroy does - if the data is deleted then it's
> deleted, how can it be accessible and why?
>

With AJAX or browser supports concurrent access to server,
concurrent access to server is possible.

When session ID is regenerated, it is possible that some connections access
to
server with old session ID. i.e. Race condition.

When this happened, old session that may be known to attacker may be
reinitialized or new unneeded session ID is created when use_strict_mode=On.

Allowing access to old session data for a while prevents these cases that
initialize
unneeded session.

RFC proposes deletion flag in $_SESSION. It's a little dirty,
but it's faster and simpler. It would be acceptable because the session is
deleted one.


Also, do I understand correctly that the options would apply only to
> files module? If so, why they under session.* and not session.files.* or
> something to emphasize that if you're not using files module it doesn't
> do anything?


No. It's applicable to all save handlers.

files save handler is default save handler and there were comments that
 want separate implementation for files. That's the reason why there is
such
voting option.

files and files_ext would be identical code except the code supports
proposed options. I would like to have single code for easier maintenace.
IMHO.

Thank you for the comment.
I hope everyone understands idea behind this RFC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c25dea26e72604f05f50f7--