Hi,
On Fri, Mar 14, 2014 at 12:30 PM, Patrick Schaaf <[email protected]> wrote:
>
> Am 14.03.2014 11:07 schrieb "Andrey Andreev" <[email protected]>:
>
>
>>
>> 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.
It is not broken functionally, indeed.
It's broken by design - if I write session_start(), options or not, I
would never expect it to immediately close the session. It's highly
misleading and this will lead to a lot of abuse.
Cheers,
Andrey.