Hi Stas,
On Mon, Jan 20, 2014 at 11:56 AM, Stas Malyshev <[email protected]>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
[email protected]