Doc #55624 [Csd]: session_set_save_handler should mention locking
| From: | yohgaki@php.net | 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