Re: Solution for session_regenerate_id() issues

Hi Chris, On Fri, Mar 14, 2014 at 7:37 PM, Chris Wright <daverandom@php.net> wrote: > For me, an arbitrary delay time is not a solution to this. The point > of this (unless I misunderstand) is to prevent session hijacking with > the old session ID, and simply reducing the the time window where this > can happen doesn't really solve anything, as I see it. > > The only flow that makes sense to me (aside from simply nuking the old > session data immediately when the ID is regenerated) goes as follows: > > - A request regenerates the session ID > - The old session data is somehow marked as read-only. > - All outstanding requests that the server has *already received* that > are blocked waiting for a lock on the session are able to access the > old data on a read-only basis. > - When the last one of these requests has been processed, destroy the > old session data. > > I realise this is likely impractical to implement in such a way that > it works reliably (or even at all) with every SAPI. > Indeed, there is no way to enforce serialized access to resources... Hence I believe the only *practical* solution here is simply to > educate users and encourage the use of session_regenerate_id(TRUE) in > the documentation. > > If session_regenerate_id(TRUE) is reliable, then it's not an issue. However, session_regenerate_id(TRUE) is unreliable. Apps that suddenly logout would not be an option for almost all developers. Feasible solution is to allow some window of risks. I agree that there is risk, but the risk is reduced a lot with this. The window is configurable, too. Current risk enforced by default (i.e. session_regenerate_id(FALSE)) is too much to accept. If session_regenerate_id(TRUE) could be used for an app, it's still possible to delete old data immediately. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net