(02-13-2015, 10:41 AM)lvrkln Wrote: The 'files' session handler is not a compatible replacement for the 'native' session handler. There are libraries and middleware that may interact with the PHP native session functions and global $_SESSION directly. The AWS DynamoDB session handler, for example, worked by injecting itself into native handler without having to write a driver class.
Additionally, the removal of the "sess_expire_on_close" config setting prevents us from controlling the native session configuration of the cookie. There are many use cases where an application might need the session to survive a browser restart, etc.
I feel like we should support the old 'native' session handler with the new SessionHandlerInterface.
Well, you have to have in mind that the "old" 'native' session handler was never a released feature. It was merged as an alternative to the old cookie-based implementation, which had countless flaws.
However, an alternative is not a real solution, hence why the whole thing was rewritten from scratch and each of the available drivers registers itself as a real, PHP-level session handler (interacting with PHP native functions, $_SESSION and such). The four drivers that are available by default cover the needs of no less than 95% of our users (that's an educated guess), and for the rest of you - you can still write your own handler.
That being said, I've thought ot adding a 'native' driver to the current implementation, for the sole purpose of allowing the users to pick one of the handlers that are available in PHP as extensions. There's a slight problem with that however ... in order to provide the 'sess_match_ip' functionality
for real (at the storage level, not by setting it as a session variable), we'll have to rely on extending the SessionHandler (that's a PHP class exposing its underlying implementation to userspace) class, which in turn has its quirks. SessionHandlerInterface has nothing to do with that ... that's an also an interface provided by PHP itself (that is implemented by the SessionHandler class), so it would be irrelevant to a possible 'native' driver.
In general, I'm not opposed to the idea, but so far nothing has justified the effort. In any case, it won't happen in time for the 3.0 release.
And a note about 'sess_expire_on_close' ... the setting's removal prevents you from nothing.
Judging by what you wrote, you don't really understand what it does either ... It's not for allowing a session to survive a browser restart (that's how sessions work by default), but to force a session's expiration once the browser is closed.
It is a very simple concept - don't give the cookie an expiry time value, so the browser will keep the cookie until you close it, after which the garbage collector will take care of deleting it. Only ... the GC doesn't know anything about cookies, so you may have your browser open for days and still have the session cookie, but the garbage collector doesn't keep stuff in storage for that long and will invalidate it.
TL;DR: 'sess_expire_on_close' is the equivalent of 'sess_expiration' = 0. It's the
exact same thing and having two settings for it is just pointless.
