Hi Chris,
On Fri, Mar 14, 2014 at 7:37 PM, Chris Wright <[email protected]> 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
[email protected]