php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #55624 session_set_save_handler should mention locking
Submitted: 2011-09-06 17:41 UTC Modified: 2016-10-17 21:30 UTC
Votes:2
Avg. Score:3.5 ± 1.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: tyrael@php.net Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tyrael@php.net
New email:
PHP Version: OS:

 

 [2011-09-06 17:41 UTC] 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-17 11:21 UTC] yohgaki@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: yohgaki
 [2016-10-17 11:40 UTC] 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:56 UTC] yohgaki@php.net
"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.
 [2016-10-17 12:01 UTC] narf at devilix dot net
That may be enough on the new section you've created, but this issue is explicitly about the examples on https://secure.php.net/session_set_save_handler

Many users use that as a reference or just straight copy-paste from there, and there are zero mentions of locking on that page.
 [2016-10-17 18:26 UTC] yohgaki@php.net
BTW, I'm going to fix session save handler's mess soon, object interface interface especially.

IIRC, I've written full procedural save handler implementation many years ago that includes exclusive locks in the manual that includes precise return data types for each handler. This was removed from the manual somehow, and replaced by OO only description which lacks many aspects. I might have written this in somewhere else. It's very long time ago.

Current manual page lacks create_sid, validate_sid, update_timestamp handler description, even if validate_sid handler implementation is mandatory absolutely. Since I implemented validate_sid, I'm certain that I've written manual for this. The manual page is gone also.

I shall write complete manual page when save handler mess is corrected.
 [2016-10-17 21:30 UTC] yohgaki@php.net
Added minimum description by commit 340522
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 07:01:27 2024 UTC