Re: Re: Revert session_serializer_name(), session_gc()

Hi, On Fri, Mar 14, 2014 at 12:30 PM, Patrick Schaaf <bof@bof.de> wrote: > > 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. 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.