Hi Yasuo,
Am 23.10.2013 02:56 schrieb "Yasuo Ohgaki" <[email protected]>:
>
> On Tue, Oct 22, 2013 at 8:10 PM, Patrick Schaaf <[email protected]> wrote:
>>
>> Working on the issue for our own application, I'm in the process of
teaching our session wrapping class to regenerate ID often - but when doing
so, first setting up the previous session ID with two pieces of
information: a short timeout of 20 seconds or something like that, and a
"forwarding ID" which references the new session ID.
>>
>> I want to do this because I want to regenerate IDs often (also based on
a rather short timeout), and I'm concerned about parallel in-flight
requests - a high probability reality with ajax getting more and more
traction - still presenting the old session ID a second or two after a
request determined to regenerate.
>
> Session save handlers lock session data to avoid mess, but your approach
works without lock
> in many cases. However, it may result in inconsistent session data (i.e.
over written data),
> so I would not recommend it as general usage.
While true for us, that is a separate issue. The parallel in-flight
requests meeting an invalidated session, will happen as well with fully
locked sessions - for example they will wait on the lock for the old
session ID while the regenerating script is still before the regeneration
point. When the lock is lifted (with regenerate(true)) they will then see
an empty session, potentially affecting their operation due to missing
context.
Regarding non-full session locking, going that way is a conscious decision
for us. We find that most of the time the session data we use is readonly,
i.e. a once set up set of contextual information is used but not modified
by e.g. additional ajax requests. Full locking in these cases, coupled with
the occasional longer running script, results in full serialization of
request processing, which translates into much increased total latency for
the end user.
Thus, our general approach is to shortly open the session, capturing
$_SESSION to class static storage, and closing the session again. Setter
methods of our helper class then maintain a dirty flag, and at the end of
the script run (or explicitly called), a "flush" method examines that dirty
flag, and only when dirty, it opens the session again and replaces all
session variables with the full set of variables modified by that script
(so no modifications of several parallel scripts are mixed together -
simple last-one-wins, which makes reasoning about correctness somewhat
easier).
> The main idea of this proposal is "Making PHP secure by default".
> It does not worth to keep insecure default forever because of the initial
implementation
> had bug. IMHO.
I'm fully agreed on changing the default!
> BTW, I prefer not to raise errors for "false", since it has valid usage
Exactly.
best regards
Patrick