When a session expiration time is defined, is it possible to call an event listener when it expires?
If it is not possible, is it possible to run a cron job to check if a session has expired?
NOTE: I'm interested in a server solution. I'm talking about the case there is a session expiration time defined, and the session finishes automatically because that period expired.
You need to use session_encode() and session_decode(). The former will only read data from the $_SESSION array so eavesdropping on sessions requires some careful subversion of session_id() and session_start() .
You can check the HttpContext. Current. User. Identity.
Session Expire itself means that your web page has lost its connectivity to internet and it is no more active page(user data also expired) so it cannot re-direct to login page itself. Once a request is made to site again, it will automatically redirect request to login page.
Answer. Yes the Session cookie expires. In addition to the 30 minute default timeout (if the visitor is idle for 30 minutes) the 'Session ID' cookie will expire at the end of an internet browser session.
is it possible to call an event listener when it expires?
The short answer is NO
There are a few oddities people tend to ignore about sessions. With the default handler, the session does not expire when gc_maxlifetime
ends - this is just the time at which the data becomes eligible for automatic deletion. There is no action by the owner of the session which triggers the subsequent removal of the session - its a side effect of someone else's session.
When session_write_close()
is called (either explicitly, or implicitly by the code ending), if the random number generator, tweaked by the relevant gc settings throws the right number then PHP will go looking for data past its TTL and remove it. If you want to trigger an action at this point, then you need to break the default handler and apply your own. That means you not only have to provide a mechanism for identifying and removing sessions but also a way of deciding whether your handler should kick in and how many sessions it should delete - you don't want a runaway process killing your server.
In Ubuntu, session.gc_probability = 0
, and it is a cron job which carries out the function of removing stale data files.
A very important piece of information missing from your question is the reason for deleting the session.
If you want to prevent sensitive data from persisting on the filesystem, then a better solution is to encrypt the data using a key stored (only) in another client side cookie. That way you completely eliminate the storage of unprotected data on your server. (note that suhosin's encrypted sessions use a key derived from data about the client and a static key stored on the same host - this is significantly less secure than a randomly generated key). Here's one I prepared earlier.
If you merely want to prevent access after the gc_maxlifetime
has expired, you should consider a custom session handler which treats a stale session as missing. i.e. it doesn't really logout at expiry, but any subsequent requests can no longer be associated with the session. The security layer in the Stackable session handler examples implements such a control.
OTOH if you want to use data from within the session in your event listener, then that's a different story - you certainly won't be able to use either Suhosin's or my encryption for the data. But a further complication is that the (default) format for the data is different from that used elsewhere. You need to use session_encode() and session_decode(). The former will only read data from the $_SESSION array so eavesdropping on sessions requires some careful subversion of session_id()
and session_start()
. session_decode()
however will happily convert anything you throw at it.
In recent versions of PHP you can specify a different function pair to use for serialization/deserialization.
It is vitally important to consider the potential impact of __wakeup()
methods when considering a session garbage collector which is going to read the data in the session files. Related to this is a requirement that the process which handles such garbage collection runs under the same uid as the original PHP process which created the session data (otherwise you have a privilege escalation backdoor). But if the session storage substrate is file-based then that would need to be the case anyway.
There are implementations of session data deserializer written in languages other than PHP which would provide protection against __wakeup()
attacks (try Google) although that might be overkill to solve the problem and they are probably not being actively maintained. If this is a concern then a more appropriate solution might be to use the WDDX (xml) serializer and use a conventional XML parser to read the data back in your GC engine.
If you are using the native handler for normal reading and writing of the data but want to implement your own garbage collector then you're going to need code to map the session_id
to a file path. If you follow the link I gave to the PHP classes above, you'll see pure PHP implementation of several session handlers, including ones which are compatible with the native handler.
But I would strongly encourage you to exhaust every other avenue for solving whatever the underlying problem is before choosing to read back session data at the time of deletion.
You can also use this :)
<?
session_start();
$time = 3600; // Set expire time with secends.
// Star session here
if (isset($_SESSION['time']) && (time() - $_SESSION['time']) > $time) {
// Your Code Here to logout
header('location: /auth/logout');
exit();
} else {
$_SESSION['time'] = time();
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With