Doc #55624 [Csd]: session_set_save_handler should mention locking

From: Date: Mon, 17 Oct 2016 11:56:05 +0000
Subject: Doc #55624 [Csd]: session_set_save_handler should mention locking
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-14022@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55624&edit=1 ID: 55624 Updated by: yohgaki@php.net Reported by: tyrael@php.net Summary: session_set_save_handler should mention locking Status: Closed Type: Documentation Problem Package: Session related PHP Version: Irrelevant Assigned To: yohgaki Block user comment: N Private report: N New Comment: "Session data is locked to avoid races by default. Locking is mandatory to keep session data consistent across requests." Isn't this enough? I agree this isn't enough for beginners, though. Previous Comments: ------------------------------------------------------------------------ [2016-10-17 11:40:46] narf at devilix dot net Why is this closed with a link to http://php.net/manual/en/features.session.security.management.php#features.session.security.management.session-locking ? The issue was about adding flock() calls to the examples on session_set_save_handler() ([1]) and warning them against the dangers of NOT using locks. It was NOT about scaring users away from locking with talks about DoS attacks. * [1] http://php.net/manual/en/function.session-set-save-handler.php ------------------------------------------------------------------------ [2016-10-17 11:21:21] yohgaki@php.net This is documented in session security section now. http://php.net/manual/en/features.session.security.management.php#features.session.security.management.session-locking ------------------------------------------------------------------------ [2013-01-16 19:26:32] googleguy@php.net Related To: Bug #63278 ------------------------------------------------------------------------ [2011-09-06 17:41:10] tyrael@php.net Description: ------------ I've learned a couple of years ago the hard way that the default session handler uses locking(flock) for locking the session files, so there couldn't be two concurrent script execution with the same session id. However when people started using their own session handlers, they usually get the concept from the example in the php manual, which doesn't mention that what are the pros/cons for serializing the session execution. I would suggest to add the flock call to the example implementation, and add a note about the potential problems if no locking mechanism is implemented (potential dataloss, concurrent requests can overwrite each others data, that there is no guarantee that two ajax request will be served in the same order, etc.). heck, even the memcache ext (http://pecl.php.net/package-changelog.php? package=memcache) was bitten by this problem. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=55624&edit=1

« previous php.doc.bugs (#14022) next »