The SessionHandler class
(PHP 5 >= 5.4.0)
Introduction
SessionHandler a special class that can be used to expose
the current internal PHP session save handler by inheritance. There are six methods which
wrap the six internal session save handler callbacks (open, close,
read, write, destroy and gc).
By default, this class will wrap whatever internal save handler is set as as defined by the
session.save_handler configuration directive which is usually
files by default.
Other internal session save handlers are provided by PHP extensions such as SQLite (as sqlite),
Memcache (as memcache), and Memcached (as memcached).
When a plain instance of SessionHandler is set as the save handler using session_set_save_handler() it will wrap the current save handlers. A class extending from SessionHandler allows you to override the methods or intercept or filter them by calls the parent class methods which ultimately wrap the interal PHP session handlers.
This allows you, for example, to intercept the read and write
methods to encrypt/decrypt the session data and then pass the result to and from the parent class.
Alternatively one might chose to entirely override a method like the garbage collection callback
gc.
Because the SessionHandler wraps the current internal save handler methods, the above example of encryption can be applied to any internal save handler without having to know the internals of the handlers.
To use this class, first set the save handler you wish to expose using session.save_handler and then pass an instance of SessionHandler or one extending it to session_set_save_handler().
Please note the callback methods of this class are designed to be called internally by PHP and are not meant to be called from user-space code. The return values are equally processed internally by PHP. For more information on the session workflow, please refer session_set_save_handler().
Class synopsis
This class is designed to expose the current internal PHP session save handler, if you you want to write your own custom save handlers, please implement the SessionHandlerInterface interface instead of extending from SessionHandler.
Example #1 Using SessionHandler to add encryption to internal PHP save handlers.
<?php
class EncryptedSessionHandler extends SessionHandler
{
private $key;
public function __construct($key)
{
$this->key = $key;
}
public function read($id)
{
$data = parent::read($id);
return mcrypt_decrypt(MCRYPT_3DES, $this->key, $data, MCRYPT_MODE_ECB);
}
public function write($id, $data)
{
$data = mcrypt_encrypt(MCRYPT_3DES, $this->key, $data, MCRYPT_MODE_ECB);
return parent::write($id, $data);
}
}
// we'll intercept the native 'files' handler, but will equally work
// with other internal native handlers like 'sqlite', 'memcache' or 'memcached'
// which are provided by PHP extensions.
ini_set('session.save_handler', 'files');
$handler = new EncryptedSessionHandler('mykey');
session_set_save_handler($handler, true);
session_start();
// proceed to set and retrieve values by key from $_SESSION
Note:
Since this class' methods are designed to be called internally by PHP as part of the normal session workflow, child class calls to parent methods (i.e. the actual internal native handlers) will return
FALSEunless the session has actually been started (either automatically, or by explicit session_start(). This is important to consider when writing unit tests where the class methods might be invoked manually.
Table of Contents
- SessionHandler::close — Close the session
- SessionHandler::destroy — Destroy a session
- SessionHandler::gc — Cleanup old sessions
- SessionHandler::open — Initialize session
- SessionHandler::read — Read session data
- SessionHandler::write — Write session data
Коментарии
As the life-cycle of a session handler is fairly complex, I found it difficult to understand when explained using just words - so I traced the function calls made to a custom SessionHandler, and created this overview of precisely what happens when you call various session methods:
https://gist.github.com/mindplay-dk/623bdd50c1b4c0553cd3
I hope this makes it considerably easier to implement a custom SessionHandler and get it right the first time :-)
Here is a wrapper to log in a file each session's operations. Useful to investigate sessions locks (which prevent PHP to serve simultaneous requests for a same client).
Just change the file name at the end to dump logs where you want.
class DumpSessionHandler extends SessionHandler {
private $fich;
public function __construct($fich) {
$this->fich = $fich;
}
public function close() {
$this->log('close');
return parent::close();
}
public function create_sid() {
$this->log('create_sid');
return parent::create_sid();
}
public function destroy($session_id) {
$this->log('destroy('.$session_id.')');
return parent::destroy($session_id);
}
public function gc($maxlifetime) {
$this->log('close('.$maxlifetime.')');
return parent::gc($maxlifetime);
}
public function open($save_path, $session_name) {
$this->log('open('.$save_path.', '.$session_name.')');
return parent::open($save_path, $session_name);
}
public function read($session_id) {
$this->log('read('.$session_id.')');
return parent::read($session_id);
}
public function write($session_id, $session_data) {
$this->log('write('.$session_id.', '.$session_data.')');
return parent::write($session_id, $session_data);
}
private function log($action) {
$base_uri = explode('?', $_SERVER['REQUEST_URI'], 2)[0];
$hdl = fopen($this->fich, 'a');
fwrite($hdl, date('Y-m-d h:i:s').' '.$base_uri.' : '.$action."\n");
fclose($hdl);
}
}
ini_set('session.save_handler', 'files');
$handler = new DumpSessionHandler('/path/to/dump_sessions.log');
session_set_save_handler($handler, true);
Your custom session handler should not contain calls to any of the session functions, such as session_name() or session_id(), as the relevant values are passed as arguments on various handler methods. Attempting to obtain values from alternative sources may not work as expected.php -S localhost:8000 -t foo/
touch index.php
vi index.php
============================================================
class NativeSessionHandler extends \SessionHandler
{
public function __construct($savePath = null)
{
if (null === $savePath) {
$savePath = ini_get('session.save_path');
}
$baseDir = $savePath;
if ($count = substr_count($savePath, ';')) {
if ($count > 2) {
throw new \InvalidArgumentException(sprintf('Invalid argument $savePath \'%s\'', $savePath));
}
// characters after last ';' are the path
$baseDir = ltrim(strrchr($savePath, ';'), ';');
}
if ($baseDir && !is_dir($baseDir) && !@mkdir($baseDir, 0777, true) && !is_dir($baseDir)) {
throw new \RuntimeException(sprintf('Session Storage was not able to create directory "%s"', $baseDir));
}
ini_set('session.save_path', $savePath);
ini_set('session.save_handler', 'files');
}
}
$handler = new NativeSessionHandler("/var/www/foo");
session_set_save_handler($handler, true);
session_start();
$a = $handler->write("aaa","bbbb");var_dump($a);exit;
============================================================
output：bool(false)
I made this gist to provide a complete overview of the PHP session handler life cycle updated to version 7.0 or above. In particular, I wanted to emphasize what methods and in what order are called when the native PHP functions are used for session management.
https://gist.github.com/franksacco/d6e943c41189f8ee306c182bf8f07654
I hope this analysis will help all the developers interested in understanding in detail the native session management performed by PHP and what a custom session handler should do.
Any comment or suggestion is appreciated.
The best way to set up your own session handler is to extend the native SessionHandler (override the 7 methods + constructor as per your need, keeping the same signatures). Optionally, you can also implement SessionUpdateTimestampHandlerInterface if you plan to use 'lazy_write':
Option 1:
class MyOwnSessionHandler extends \SessionHandler { ..... }
Option 2:
class MyOwnSessionHandler extends \SessionHandler implements \SessionUpdateTimestampHandlerInterface { ..... }
I would NOT recommend to do this:
class MyOwnSessionHandler implements \SessionHandlerInterface, \SessionIdInterface, \SessionUpdateTimestampHandlerInterface { ... }
If you are curious, here are the methods called in the order (using PHP 8.2 with XAMPP v3.3.0 on Windows 11 64-bit):
- open (always called)
- validateId and/or create_sid:
validateId is called if you implement SessionUpdateTimestampHandlerInterface. If validation fails, create_sid is called.
create_sid is called if a new session ID is needed: new session, etc.
- read (always called)
- write OR updateTimestamp OR destroy:
if you call 'destroy', neither 'write' or 'updateTimestamp' is called,
if you have the 'lazy_write' on AND implemented SessionUpdateTimestampHandlerInterface,
then 'updateTimestamp' is called instead of 'write' if nothing changes.
- close (always called)
Those who are planning to implement your own SessionHandler, let's say using a Database system, please make sure your 'create_sid' method creates a new record in your database with empty string '' as your 'data' using the new session ID created, otherwise when 'read' method is called (which is always called no matter if it is a brand new session or not), you will get an error because there is no record with that session ID yet. The funny part is that the error you get will sound like PHP is trying open the session on your local drive (coming from your .ini file).Be aware that when you inherit from \SessionHandler you implicitly disable session strict mode because it doesn't implement SessionUpdateTimestampHandlerInterface (see: https://www.php.net/manual/en/session.configuration.php#ini.session.use-strict-mode) thus validateId() is not called.
It's CRUCIAL to call the session_regenerate_id() function whenever any privilege level is changed (i.e. during authentication, password/permission/user role change) to mitigate the session fixation attack!