Hi Mateusz, On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski <s...@digitalsun.pl> wrote:
> Doh, it's happening again, it was discussed before. Anyway, your solution > seems to not fix the real problem behind the bug entry. I suspect that > following scenario may occur: > Of course it was. I remember well. Discussion was not going well because people does not understand nature of web session. i.e. Session management is asynchronous. It works almost always under stable network, but it cannot with unstable network. > > http://lxr.php.net/xref/PHP_5_4/ext/session/mod_files.c#429 > > scenario could be as follows: > > 1. request A is done with sessid=123 > 2. A calls session_regenerate_id and is preempted after unlink(2) but > before > access(2) > 3. request B is done with sessid=123 - session_start creates the session > 4. request A wakes up, session is written to fs by request B, so destroy > fails > > Please note that if destroy fails, then new session is not generated, > possible (but ugly) solution is to call session_regenerate_id again. > It just does not work. How do you keep session for lost session? Lost session occurs like 1. Server executes session_regenerate_id(true), delete old data and send new session ID with copied data to browser. 2. Unstable network lost packet that sets new session ID. 3. Browser thinks old session ID is valid, but there is no session data for it. Besides, there is issue that session data must be deleted may keep alive forever. Current session management is not predictable and precise at all. If there is better idea other than the RFC, I appreciate it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
