-
Notifications
You must be signed in to change notification settings - Fork 1
Session handler
The YapepBase framework uses a custom session handling mechanism instead of PHP's built in mechanism. In most cases the session as accessed while serving an HTTP request, but the framework supports writing session handlers that may access the HTTP session from a batch script, or an HTTP request coming from an external provider API, that needs to modify a normal HTTP client's session.
The session handler system allows having multiple sessions for a client. This is useful if the site has 2 distinct logged in areas, for example a member and an administration area. Since the sessions are distinct modifying one of the sessions does not affect the other, and (if using separate session cookie names) destroying one of them on logging out will not destroy the other.
For this reason the \YapepBase\Session\SessionRegistry
is used to register any defined sessions, which should be done in either the index.php or the bootstrap.php.
The session handlers use the Event system for loading and saving the session data. The session data is loaded on the \YapepBase\Event\Event::TYPE_APPSTART
event, and saved on the \YapepBase\Event\Event::TYPE_APPFINISH
event, both of which are dispatched by the \YapepBase\Application
for HTTP requests, or the \YapepBase\Batch\BatchScript
for batch scripts.
The session handlers implement the ArrayAccess interface. Be careful when working with arrays in the session, since it is possible to treat any ArrayAccess implementation as multidimensional arrays when reading, but when modifying any such value, it will not be saved in the object.
Sessions are identified by their namespace in the session registry. The registered session handlers can be retrieved by their namespaces.
The create()
method is used to create or recreate a session. It's called automatically when loading the session and a session ID is not set. If a session ID is set, the old session will be destroyed, and a new session ID will be generated.
The destroy()
method is used to destroy a session. Destroying a session will delete all session data, and invalidate the session ID.
This is the default implementation of the session handling, that should be used when the request is an HTTP request and the response is directly sent to the client. This means this handler should not be used if the request is for an API, because we most likely won't be able to set a cookie for the API client.
With this handler the session ID is stored in a cookie. The cookie's name, lifetime, domain and path are configurable. In addition there is a configuration option that sets whether the session cache limiting headers should be sent to the client. These headers are used to stop any proxies on the way, or the client from caching the response. In most cases session cache limiting should be enabled (which is the default behavior). For more information see the PHP manual on session cache limiters.