Re: Solution for session_regenerate_id() issues

From: Date: Mon, 17 Mar 2014 11:00:34 +0000
Subject: Re: Solution for session_regenerate_id() issues
Groups: php.internals 
Request: Send a blank email to internals+get-73213@lists.php.net to get a copy of this message
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.

« previous php.internals (#73213) next »