Hi Dan,
On Fri, Jan 8, 2016 at 12:54 AM, Dan Ackroyd <dan...@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
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
