Re: Re: Revert session_serializer_name(), session_gc()
| From: | Patrick Schaaf | Date: | Fri, 14 Mar 2014 10:30:14 +0000 |
| Subject: | Re: Re: Revert session_serializer_name(), session_gc() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-73154@lists.php.net to get a copy of this message | ||
Am 14.03.2014 11:07 schrieb "Andrey Andreev" <narf@devilix.net>:
>
> This is broken, consider the following (multiple tab/ajax/whatever
> concurrency) scenario:
>
> Request1: session_start(['read_only' => TRUE]);
> Request2: session_start(); unset($_SESSION['logged_in']);
session_commit();
> Request1: still logged in
>
> ^ This screams "danger".
That is _not_ broken WRT sessions themselves, because the readonly session
of request 1 will not be permitted to change session data (it is readonly)
and as such the situation is the same as if request 1 completed before
request 2 started.
It _is_ broken when the session lock is "misused" as a lock wrt. other,
nonsession data / database modifications / whatever else. In that case,
using the readonly session feature or any other kind of different-lifetime
session lock scheme is bad for the application - don't do that then.
best regards
Patrick