Cloud Firestore Client - Class FirestoreSessionHandler (1.40.0)

Reference documentation and code samples for the Cloud Firestore Client class FirestoreSessionHandler.

Custom session handler backed by Cloud Firestore.

Instead of storing the session data in a local file, this handler stores the data in Firestore. The biggest benefit of doing this is the data can be shared by multiple instances, making it suitable for cloud applications.

The downside of using Firestore is that write operations will cost you some money, so it is highly recommended to minimize the write operations while using this handler. In order to do so, keep the data in the session as limited as possible; for example, it is ok to put only signed-in state and the user id in the session with this handler. However, for example, it is definitely not recommended that you store your application's whole undo history in the session, because every user operation will cause a Firestore write, potentially costing you a lot of money.

This handler doesn't provide pessimistic lock for session data. Instead, it uses a Firestore transaction for data consistency. This means that if multiple requests are modifying the same session data simultaneously, there will be more probablity that some of the write operations will fail.

If you are building an AJAX application which may issue multiple requests to the server, please design your session data carefully in order to avoid possible data contentions. Also please see the 2nd example below for how to properly handle errors on write operations.

The handler stores data in a collection formatted from the values of session.save_path and session.name, which can be customized using the $collectionNameTemplate option. This isolates the session data from your application data. It creates documents in the specified collection where the ID is the session ID. By default, it does nothing on gc for reducing the cost. Pass a positive value up to 500 for $gcLimit option to delete entities in gc.

The first example automatically writes the session data. It's handy, but the code doesn't stop even if it fails to write the session data, because the write happens when the code exits. If you want to know whether the session data is correctly written to Firestore, you need to call session_write_close() explicitly and then handle E_USER_WARNING properly. See the second example for a demonstration.

Example:

use Google\Cloud\Firestore\FirestoreClient;

$firestore = new FirestoreClient();

$handler = $firestore->sessionHandler();

session_set_save_handler($handler, true);
session_save_path('sessions');
session_start();

// Then write and read the $_SESSION array.
$_SESSION['name'] = 'Bob';
echo $_SESSION['name'];

// Session handler with error handling:
use Google\Cloud\Firestore\FirestoreClient;

$firestore = new FirestoreClient();

$handler = $firestore->sessionHandler();
session_set_save_handler($handler, true);
session_save_path('sessions');
session_start();

// Then read and write the $_SESSION array.
$_SESSION['name'] = 'Bob';

function handle_session_error($errNo, $errStr, $errFile, $errLine) {
    // We throw an exception here, but you can do whatever you need.
    throw new RuntimeException(
        "$errStr in $errFile on line $errLine",
        $errNo
    );
}
set_error_handler('handle_session_error', E_USER_WARNING);

// If `write` fails for any reason, an exception will be thrown.
session_write_close();
restore_error_handler();

// You can still read the $_SESSION array after closing the session.
echo $_SESSION['name'];

Create a custom session handler backed by Cloud Firestore.

Start a session, by getting the Firebase collection from $savePath.

Close the transaction and commit any changes.

Read the session data from Cloud Firestore.

Write the session data to Cloud Firestore.

Delete the session data from Cloud Firestore.

Delete the old session data from Cloud Firestore.