[RFC] Introduce session.lock, session.lazy_write and session.lazy_destory

Hi all, On Sat, Dec 21, 2013 at 7:25 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

I would like to setup vote for this RFC soon. (Hopefully, prepare the patch soon) Most issues are already discussed. If you have comments, please send mail. Especially, if you have better INI names, I appreciate it. Thank you.

Hi all, On Sat, Dec 21, 2013 at 7:25 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

I've added session_discard() to RFC that discards changes made to session data and close session. Since there is session_commit(), http://www.php.net/manual/en/function.session-commit.php session_abort() may be better name for it. Any comment? Regards,

Hi, While I agree with the rationale for wanting more advanced behaviour from the session management functionality in PHP, I don't think adding more functionality to the built in session_* functions will give a result that is satisfactory. The problem is that most of the information about how the sessions should be managed lives at the application level. It will also vary within an application depending on what the user is doing. Some examples, from the RFC: Session locking - If an application knows that it won't be writing any data to the session, it should be able to read the session data without ever locking the session data. There are also session write operations that just don't need any locking at all. For example if you want to just record the number of pages a user has viewed since they logged in: $_SESSION['pagesViewed']++; With a Redis storage backend for the session data, this can be done without any locking at all, if the application is written without assuming that the session data will be locked. Race condition around regenerated session IDs - The proposal to allow clients that try to use a session ID that has recently been regenerated would not be acceptable for all clients. Some clients would probably prefer to send a HTTP error code (419 Authentication Timeout?) indicating that the client should resend the request with the new session ID. It's also likely that applications would want to allow recently regenerated session IDs to be allowed for read operations, but not for write operations. The previous discussions about improving security for sessions are another example of where the logic isn't simple and what exactly happens when the client changes either I.P. address or useragent during a session is totally dependent on the application. i.e. for a banking application, if the user ever changes IP address, then it would be acceptable to instantly terminate that session. For a shopping application, if the user changes IP address to one that is within a close geographical aread as the original IP address, then the application could let that session continue, and only terminate the session if the new IP address appeared to be physically far away from the original IP adress. Also there are already 26 ini settings for handling the sessions in PHP (ignoring the ini settings related to tracking upload progress). This a pretty clear indication that the handling of sessions is already too complex to be controlled through ini settings alone. At the risk of setting myself up for a fall, I'm going to make a proof of concept userland session manager to try and implement as many of the features under discussion in the various session related RFCs that are open as possible, and will try to publish it in a week or so. It probably won't be anywhere near production ready, but hopefully will provide a basis for discussing moving the session handling from the session_* functions to something that allows people to define the logic in code, rather than being forced to tweak a huge number of config settings. cheers Dan On Sat, Dec 21, 2013 at 10:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: