Hi Bishop,
On Wed, Jul 20, 2016 at 9:47 AM, Bishop Bettini <bis...@php.net> wrote:
>> To decide next move, I would like to start hearing the reason why from
>> those who are against this RFC.
>
>
> I abstained from voting. While I would be a "Yes" in principle, two specific
> statements in the RFC made me wary of following that instinct:
>
> 1. "external session data storage may have noticeable impact"
> 2. "lost sessions are far better than stolen sessions"
>
> I can hand waive the first one away, as performance can be optimized
> usually. But I can't really agree that, in general, lost sessions are "far
> better" than stolen ones: if lost sessions happen 1% of the time, and stolen
> sessions happen .001% of the time, then to me lost sessions are worse.
Thank you for feedback!
1. This overhead could be avoided. I'll add this to my task list.
2. This could be avoided by timestamp based session management.
Lost sessions could happen:
- When session_regenerate_id(true) which deletes old session data immediately.
by:
a. Race condition in browser by multiple requests. (Result in empty session ID)
b. Race condition between server and browser by multiple requests.
(Result in empty session data)
c. Unstable network connection. (Server use new session ID, but
browser didn't get new ID. Result in empty session data)
It is advised to change session ID periodically. Obsolete(old) session data
should be _deleted_. i.e. Simply calling session_regenerate_id() is
not good enough because delete flag is false by default. However
immediate removal causes above races. Therefore, short TTL for
obsolete session is required.
Chance of c. does not change regardless of session.use_strict_mode.
session.use_strict_mode=1 increases chance of a. and b. because session
module will try to set new session ID many times. e.g. Session could be
expired while browser is loading resources. It uses multiple connections for
access to images, css, js, etc. These resources could be using session for
access control, customization, etc and result in many set-cookie headers
for session. i.e. many set-cookies more chances for races.
session.use_strict_mode=0 uses supplied old session ID and less likely to
have race. i.e. No set-cookie headers are sent for new session ID.
I cannot mention specific probability change. Hopefully, it would not
be too much.
(I don't like this, so I proposed timestamp based session management RFC)
If session module removes old session data a little after
session_regenerate_id() is called, chances to have races will not increase.
This could be done by user script also. It might be an off topic, but FYI.
PHP 5.x and 7.x
--- Set TTL before regenerate and save ---
$_SESSION['TTL'] = time() + 300;
session_commit();
session_start();
session_regenerate_id(); // It simply generates and sets new session ID.
unset($_SESSION['TTL');
------------------------------------------------------------
PHP 7.x only. More efficient.
--- Set TTL before regenerate and save ---
$_SESSION['TTL'] = time() + 300;
session_regenerate_id(); // It writes and closes old session data and
// creates new session data since 7.0
unset($_SESSION['TTL'])
-----------------------------------------------------------
And check TTL value where normal session_start() is called and destroy
when it is expired.
My other declined RFC does this for users automatically (no code at all)
as well as other convenient things.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
