Stackable Session Handlers

This is not a class, but an interface (along with some example implementations). It extends the standard PHP Session Handler interface to add the capability to layer multiple handlers implementing different functionality. The resulting stack allows you to fine tune your performance and functionality to meet your exact needs using standard components.

Examples of the things which might be implemented at different layers are:

The revised interface looks like this:

implements StackableSHInterface {
__construct ( [ StackableSessionHandler $SHnext ] ) // added
public integer lastAccessed ( [ integer $lastAccess ] )    // added
public bool close void )
string create_sid ( [ string $newSID ] )  // amended
public bool destroy string $session_id )
bool gc int $maxlifetime )
string read string $session_id )
bool write string $session_idstring $session_data )
bool install ( [bool $use_create_sid=true] )    // added


Each constructor can be invoked with an object implementing the interface allowing the handlers to be stacked. Calls to each method are propogated to the lower objects. Only the topmost object is bound using session_set_save_handler().


The lastAccessed() method should return the Unix timestamp for when the session was last written. This method will typically return a value which is populated by the read() method - and hence should not be invoked prior to that (i.e. at session_start()). If a value is passed, then an object in the stack may replace this with its own lastAccess time or leave it as is. It is up to the class author to decide what action to take and whether to take the action before, after or both relative to calling the next component in the stack.

This method is critical to the operation of both the securityChecker and writeSometimes example implementations.


The install() method provides an simpler way to hook into the session handler than via session_set_save_handler() and is the recommended way to enable the custom session handler.

Normally the bottom most handler will be a storage handler.

The example classes are written to accomodate the possibility that the bottom-most component only implements the standard interface, however note that handlers which depend on knowing the lastAccess time will not work as expected.


This code demonstrates creating a stack with a security layer on top of a storage layer

require_once("handlers/");   // base class
require_once("handlers/"); // do additional security checks on session
require_once("handlers/");          // storage

$storage=new nonBlockingHandler();
$check=new securityHandler($storage); // note that the lower component in the stack is passed to the constructor

Example Implementations

In the examples below, refreshing the screen should increment a session counter. Every third refresh should trigger a regeneration of the session id. Except for a conflict when the non-blocking handler tries to access the same file as the compatible handler, you can use all of these at the same time! Indeed if you overwrite the path in one of the file-based storage handlers, you could even use them all - and have replicated sessions.