Hi Patrick,
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.
IIRC, the reason why session_regenerate_id(false) by default is
compatibility
for the same minor version release. We should have cleaned up this years
ago.
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.
"Making PHP secure by default" also achieves "Easy to learn and use".
BTW, I prefer not to raise errors for "false", since it has valid usage
with save
handlers allow disabling/without lock. e.g. memcached, mm save handlers.
Regards,
--
Yasuo Ohgaki
[email protected]