XELOS provides an integrated Session system which manages all user session related data. The core of the Session System is the XELOS/Framework/Lib/xf_session object which provides the basic api to get/set values to the user session.
Starting with XELOS 7.1 the Session System not only supports the default SQL Handler which stores all session data in the SQL database, but also a REDIS Handler to use REDIS not only for content caching (see #xf_cache), but also for storing session data.
Currently two interfaces exist which can be implemented by the provided session handlers
Interface for basic functions to allow a session backend specific storage of the dirty flag
Interface for some management functions being used by the system admin backend to allow the system admin to see all active sessions and to remove specific sessions (logout).
SQL Handler (DEFAULT)
All session data is stored in the SQL database. In case of multi-node setups the session is therefore accessible across all nodes. This is the default handler and requires no setup. It is recommended for small to medium systems and if you run only one node.
The REDIS session handler allows offloading the session data to a REDIS server. As REDIS keeps all DATA in memory this option is optimal for medium to large setups with a high number of concurrent users.
To enable the REDIS Session Backend you can use the following settings in your config.custom.php
# Enable REDIS as Session Backend define('XF_SESSION_STORAGE', 'redis'); @TODO
!note: As the REDIS session backend uses the content cache for storing dirty flag data you must use also a cache backend which uses a shared storage between nodes. Using APC/APCU in a multi-node setup with REDIS backend is not recommended.
!note: The session expired user notification is currently not supported by the REDIS Handler.
Internally the REDIS session handler uses the session handler provided by the REDIS library.
Each session has a dirty flag. In case of the default SQL handler this flag is stored in the SQL table as separate column. In case of other handlers it is stored in the content cache. To reduce loading times the users access rights are not recalculated on each page request and are stored in the session. As rights might require a recalculation (e.g. if the user joined a group or invited another user), each session can be marked as 'dirty' which causes a reload of the policies during the next call.
Session Call Process
The session is being initialized during the XF->init() call. As the session is required for keeping user data as well as database caching it must be initialized first while during the desctruction sequence it must be closed last. Closing the session is being done by the XF->shutdown() function which is registered as PHP shutdown function and therefore called after the script has finished.
In case the user logs out the XF->user->logout function calls the destroy() method on the session to force a dumping of all session data and force a new seesion id.
If the XF_MODE is set to CMD the session system uses the nonpersistent session handler which will keep the data during the script execution so that functions relying on the XF->lib->session object can use it to set and get data during the script execution, but it will not save any data beyond the script execution. All data is only kept in memory.
$XF = xf::instance(); // Set a value in the session $XF->lib->session->set('myvar', 1980); // There can be multiple page calls inbetween as long as the session is still active // Get a value from the session $XF->lib->session->get('myvar'); > 1980