Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.169 as permitted sender)
MIME-Version: 1.0
Date: Mon, 17 Mar 2014 13:00:34 +0200
Message-ID: <CAPhkiZz4bN8XQOtkeyXMArgdngHVjHY+0gf-Qnb9RY8xrxOZTg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: narf@devilix.net (Andrey Andreev)

Hi,

I don't think delaying deletion is a good idea, it just brings more
complexity to the whole process and I can't really imagine how it
would be handled, since PHP is not run as a daemon - this is the
reason why the session GC is triggered by chance instead of running as
some type of a cron job.

Applications usually handle this by not regenerating session ID during
an ajax request. Most JS frameworks would send a 'X-Requested-With:
XMLHttpRequest' header to provide a way for Ajax detection, and PHP
frameworks have helper methods to look for that header. Even if they
don't - anybody can implement a similar solution for their own
application.

With that said, I'd rather give a +1 for changing the
session_regenerate_id() default action from "don't delete" to
"delete", like you've previously suggested.

Btw, I wouldn't worry about stolen session IDs ... if somebody steals
it once, they'll do it after regeneration as well. Session ID
regeneration is only effective against brute-force attacks.

Cheers,
Andrey.