I have a form with multiple pages. I use the $_SESSION array to store the user input. Each page starts with
session_start();
Sometimes the $_SESSION variables are lost. I guess this is happens if the user remains for a too long period afk and the Garbage Collector removes then the variables.
If I understand it correctly, then the function session_status() only checks if a session has been started, and not if the garbage collector has removed recently any entries.
If the garbage collector becomes active, does he delete all entries of the $_SESSION array or just some of them? In other words, could I check if my Session expired by simply doing the following:
session_start();
if(empty($_SESSION)){
// Garbage Collecter removed entries because user was too long afk
}
The overall mechanism is not as sophisticated as you probably think.
Sessions can have several storage back-ends, the default of which is the builtin file handler, that merely creates, well, files:
The only way to link a given file with a given session is the session ID which, as you can see, is part of the file name.
Garbage collection is a file removal based on last modification time. Once it happens, files are gone forever. There's just no trace or record that the file ever existed.
In general, you don't need to worry about this case. Just make sure you define a lifetime that's long enough for your application. The default value in many systems often ranges from 20 to 30 minutes, which is fairly small. Also, make sure your app has its own session directory, so other apps with a shorter lifetime won't remove your files:
session_save_path('/home/foo/app/sessions');
ini_set('session.gc_maxlifetime', 86400); // 1 day (in seconds)
P.S. Some Linux systems disable PHP garbage collection and replace it with a custom cron script, what prevents custom locations from being cleaned up. For that reason I normally set these other directives just in case:
// Restore the default values
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);
Related
The scenario:
User logs in
Cookie is set to length of session
After 1 hour of inactivity I wish to log out the user
How I think I can solve this:
Set the session.gc_maxlifetime to 1 hour (3600)
Set the session.gc_probability to 1
Set the session.gc_divisor to 1
Therefore having a 100% certainty that garbage collection will occur on any idle session cookies after 1 hour.
My question:
All the posts and documentation I've read has never mentioned setting a gc change of 100%, therefore is it bad to do this? Is there a better way?
It's a symfony app, and long term I would like to do something like this http://symfony.com/doc/master/components/http_foundation/session_configuration.html#session-meta-data but for now I was hoping to just do something simple with session.gc_*
One post I read implies that having a 100% garbage collection chance is "cost-intensive" How do I expire a PHP session after 30 minutes? is this true? If so, how cost intensive?
Cheers!
The gc_probability and gc_divisor are there to let you define the "probability" of firing up the garbage collection (GC).
Since GC (as everything) comes with a cost, you wouldn't usually want it to run on each and every web request processed by your server - that would mean that every page opening or every AJAX request served from PHP would cause the GC to run.
So, depending on the actual server load and usage, the admin is expected to do an educated guess on how often should GC be run: once in 100, 1/10000 or 1 in million requests.
But, there's a problematic flaw in the OP's original reasoning - that garbage collection will occur on any idle session. The way I read the manual, the garbage collection will occur on ANY session, not just idle ones:
session.gc_maxlifetime integer: specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up.
So, the session (idle or not) lifetime is decided with gc_maxlifetime, while the moment of the GC being started (as said in the docs: "potentially") is really decided with gc_probability and gc_divisor.
To resume, my late answer to the question would be - I would not under normal condition have GC running at each and every request (the 1/1 scenario you mentioned), because
that seems like a serious overkill. On some level, you would probably end up with thousands (if not worse) of IFs and only once going into its THEN
you would log out ANY user on your system after 60mins, not just the idle ones.
There are much better ways of doing this.
If this isn't for something particularly secure, you can set an expiration date/length for the session cookies on the client-side. A technically minded user could tweak the expiration in this case, so you wouldn't want to use this on a bank site.
If you need something more secure, just store an expiration time along with the other session data and check against it. If it's exceeded, destroy their session and force them to log back in.
I am using CI's sessions in connection with a database. So all of our sessions are in this ci_sessions table on our database and it can get a lot of rows, considering that the session_id keep changing every 5 minutes.
Do we need to empty the table, say every one a month / week maybe?
While what #Marc-Audet said is true, if you take a look at the code, you can see it is a really lousy way to clean up sessions.
The constructor calls the _sess_gc function every time it is initiated. So, basically each request to your server if you have it autoloaded.
Then, it generates a random number below 100 and sees if that's below a certain value (by default it is 5). If this condition is met, then it will remove any rows on the session table with last_activity value less than current time minus your session expiration.
While this works for most cases, it is technically possible that (if the world is truly random) the random number generator does not generate a number below 5 for a long time, in which case, your sessions will not be cleaned up.
Also, if you have your session expiry time set to a long time (if you set to 0, CI will set it to 2 years) then those rows are not going to get deleted anyway. And if your site is good enough to get a decent amount of visitors, your DBA will be pointing fingers at the session table some time soon :)
It works for most cases - but I would not call it a proper solution. Their session id regeneration really should have been built to remove the records pertaining to the previous ids and the garbage collection really should not be left to a random number - in theory, it is possible that the required number is not generated as frequently as you wished.
In our case, I have removed the session garbage collection from the session library and I manually take care of it once a day (with a cron job .. and a reasonable session expiration time). This reduces the number of unnecessary hits to the DB and also does not leave a massive table in the DB. It is still a big table, but lot smaller than what it used to be.
Given the fact that the OP question doesn't have a CodeIgniter 2 tag, I'll answer how to deal with sessions cleanup when the database keeps growing for CodeIgniter 3.
Issue:
When you set (in the config.php file) sess_expiration key too high (let's say 1 year) and sess_time_to_update key low (let's say 5 min), the session table will keep growing as the users browse though your website, until sessions rows will expire and will be garbage collected (which is 1 year).
Solution:
Setting sess_regenerate_destroy key to TRUE (default set to FALSE) will delete an old session when it will regenerate itself with the new id, thus cleaning your table automatically.
No, CodeIgniter cleans up after itself...
Note
According to the CodeIgniter documentation:
The Session class has built-in garbage collection which clears out expired sessions so you do not need to write your own routine to do it.
CodeIgniter's Session Class probably checks the session table and cleans up expired entries. However, the documentation does not say when the clean up happens. Since there are no cron jobs as part of CodeIgniter, the clean up must occur when the Session class is invoked. I suppose if the site remains idle forever, the session table will never be cleared. But, this would be an unusual case.
CodeIgniter implements the SessionHandlerInterface (see the docs for the custom driver).
CodeIgniter defines a garbage collector method named gc() for each driver (database, file, redis, etc) or you can define your custom gc() for your custom driver.
The gc() method is passed to PHP with the session_set_save_handler() function, therefore the garbage collector is called internally by PHP based on session.gc_divisor, session.gc_probability settings.
For example, with the following settings:
session.gc_probability = 1
session.gc_divisor = 100
There is a 1% chance that the garbage collector process starts on each request.
So, you do not need to clean the session table if your settings are properly set.
When you call:
$this->session->sess_destroy();
It deletes the information in database by itself.
Since PHP7, the GC-based method is disabled by default, as per the documentation at https://www.php.net/manual/en/function.session-gc.php Stumbled upon this because a legacy application suddenly stopped working, reaching a system limitation since sessions are never ever cleaned up. A cronjob to clean up the sessions would be a good idea...
It is always good practice to clear the table. Otherwise, if your querying the session data for say creating reports or something, it will be slow and unreliable. Nevertheless, given the performance of mysql, yes do so.
I am making a session system for my website using PHP and MySQL. The idea is that a user session will last for around 5 minutes if they are inactive, and a CronJob runs every now and then and checks to see if sessions are expired, and if they are, removes the session.
The issue:
Every time someone loads their page it has to check the database to see if their session is still valid. I am wondering if in that CronJob task, I could make it find that users PHP Session and change a variable like $_SESSION['isValidSession'] and set it to false.
So once they load the page it just checks if that variable if the session is valid.
Sorry for the wall of text!
TL;DR: I want to modify session variables of different specified sessions.
Thanks.
Every time someone loads their page it has to check the database to
see if their session is still valid. I am wondering if in that CronJob
task, I could make it find that users PHP Session and change a
variable like $_SESSION['isValidSession'] and set it to false.
You have to do this regardless. When the users load their page, the system must verify whether the session exists in the database (I assume that you're using a DB).
If you run the cron job every minute, and expire all sessions older than five (which seems rather excessive? I often stay inactive on a site for five, ten, even fifteen minutes if I am reading a long page), this will automatically "mark invalid" (actually remove) the sessions.
Normally you would keep a TIMESTAMP column with the time of last update of that row (meaning that session), and the cron job would DELETE all rows with timestamp older than five minutes ago. When reloading the page, the system would no longer find the relevant session row, and deduce (correctly) that the session has expired.
However, what you want (reading a session knowing its SessionID) can be accomplished by reading in the session by the cron job (you can code the job in PHP) either loading as extant session given its ID, or by reading the DB column holding the serialized data with a SELECT SessionData FROM SessionTable WHERE id = 'SessionId'; and de-serializing it. Then you modify the inflated object, re-serialize it and store it back in the database with SQL UPDATE. Hey presto!, session has now been modified.
But be aware that this will likely cause concurrency problems with active clients, and cannot be done in SQL in one fell swoop - you can't execute UPDATE Sessions SET isInactive = 1 WHERE expiry... directly. Normally you need to read the rows of interest one by one, unserialize them and store them back, processing them with PHP code.
You can do it indirectly with two different workarounds.
One, you change your session code to use unserialized data. This will impact maintainability and performance (you can't "just add" something to a session: you have to create a column for it).
Two: you take advantage of the fact that in serialized form, "0" and "1" have the same length. That is, the serialized session containing isValidSession (name of 14 characters) will contain the text
...{s:14:"isValidSession";b:1;}...
and you can change that piece of string with {s:14:"isValidSession";b:0;}, thus making isValidSession become False. This is not particularly good practice - you're messing with the system's internals. Of course, I don't think anybody expects PHP's serialized data syntax to change anytime soon (...or do they?).
<?php var_dump($_SESSION); ?>
You should store the time of last request of the users in the database.
In the cornjob you should check users last view time and compare to current time, then check which user time has been expired.
And then update the column of database as false for expired users.
After than you can easily find out which user should be log out just by checking that colmn in database.
From the PHP manual, session.gc_probability and session.gc_divisor state that gc will occur based on this probability. I get that.
What I'm not clear on is whether this probability is on a session by session basis or overall.
So if my probability is 1% (1/100) that GC will occur, does that mean that if one session keeps getting extended, each time there is a 1% change that specific session will be cleaned up? Or does this mean that 1% of all existing sessions (as well as new ones) will trigger GC for all other existing sessions?
I'm pretty sure it's the latter, I just want to make sure.
The purpose of this question is that on our site, I want users to have long-term sessions (6 months). If 1% of all sessions trigger GC, then that effectively removes the purpose of having that long-term session, as GC will end up occurring every hour or two.
Every time a PHP script is executes and starts session there is a probability that it will sweep through the session folder killing off old session.
Cleanup will only delete sessions which were not accessed within a certain time. However PHP does not guarantee that the session WILL be destroyed within that time.
Your long-term session strategy should work just fine, but you might want to reduce 1% to something like 0.1%
Another thing to look out for is that operating system might clean up your /tmp folder during reboot so even if PHP won't do it.
last time I looked at the source each call to session_start() "rolled the dice" so to speak, using the divisor and probability. If you hit, then it would delete all files from the session.save_path directory that were older than session.gc_maxlifetime. I forget if it used modification or access time of the file, although it shouldn't matter in normal curcumstances because php overwrites the session file by default at the end of script execution, so mod and access times should almost always match very closely.
// Rough psuedo code of how php's session_start() function works regarding garbage collection.
function session_start() {
$percentChanceToGC = 100 * ini_get('session.gc_probability') / ini_get('session.session.gc_divisor');
$shouldDoGarbageCollection = rand(1, 100) < $percentChanceToGC;
if ($shouldDoGarbageCollection) {
$expiredCutoffTime = time() - ini_get('session.gc_maxlifetime');
foreach (scandir(ini_get('session.save_path')) as $sessionFile) {
if (filemtime($sessionFile) < $expiredCutoffTime) {
unlink($sessionFile);
}
}
}
// ... rest of code ....
}
I don't know how many session files you're going to end up having hang around if you want them to live for a minimum of 6 months. Consider it may take a little while for php to stat many thousands of files to determine their age. Maybe consider other options for durable storage of this data. Or you could disable php gc and just run a cron job to delete stale session files. Otherwise, that 1% of requests are gonna trigger gc and have to wait for php; in other words it could possibly lag.
I'm not an expert on this, but from reading the manual, I'd draw your attention to another setting, session.gc_maxlifetime. From the docs:
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor).
So if you set this setting to a suitable value (60 * 60 * 24 * 365 / 2 for half a year, so 15768000), then the appropriate data won't be eligible for garbage collection, no matter what the other settings are.
What is the actual difference between session.gc_maxlifetime and session_cache_expire() ?
Suppose I want the users session to be invalid after 15 minutes of non-activity (and not 15 after it was first opened). Which one of these will help me there?
I also know I can do session_set_cookie_params() which can set the user's cookie to expire in some amount of time. However, the cookie expiring and the actual session expiring on the server side are not the same; does this also delete the session when the cookie has expired?
Another solution I have though of is simple
$_SESSION['last_time'] = time()
on every request, and comparing the session to the current time, deleting the session based on that. I was hoping there was a more "built-in" mechanism for handling this though.
Thanks.
I spent some time looking for a good answer to how the php.ini server settings make
sessions expire. I found a lot of info but it took a while to figure out why
the settings work the way they do. If you're like me, this might be helpful to you:
Sessions are stored as cookies (files on the client's pc) or server side as files
on the server. Both methods have advantages and disadvantages.
For the sessions stored on the server, three variables are used.
session.gc_probability
session.gc_divisor
session.gc_maxlifetime
(session.gc_probability/session.gc_divisor) produces the probability that the
garbage collection routine will run. When the garbage collector runs, it
checks for session files that haven't been accessed for at least session.gc_maxlifetime
and deletes them.
This is all explained pretty well in forum posts (this one especially!) - But the
following questions do come up:
1.) How is that probability applied? When does the server roll the dice?
A: The server rolls the dice every time session_start() is called during
any active session on the server. So this means you should see the garbage
collector run roughly once for every 100 times that session_start() is called
if you have the default of session.gc_probability = 1 and session.gc_divisor = 100
2.) What happens on low volume servers?
A: When session_start() is called it FIRST refreshes the session and makes the
session values available to you. This updates the time on your session file on the
server. It THEN rolls the dice and if it wins (1 out of 100 chance) it calls the garbage collector. The garbage collector then checks all session id files and sees if there are
any that are eligible for deletion.
So this means that if you are the only person on the server, your session will
never go inactive and it will appear as though changing the settings have no
effect. Let's say you change session.gc_maxlifetime to 10 and session.gc_probability
to 100. This means there is a 100% chance the garbage collector will run and it
will clear out any session files that haven't been accessed in the last 10 seconds.
If you're the only one on the server, your session will not be deleted. You need
at least 1 other active session running for yours to go inactive.
So basically, on a low volume server or at a low volume time - it could be MUCH
longer than session.gc_maxlifetime before the garbage collector actually runs and
the sessions are actually deleted. And without knowing how this works, it may
appear completely random to you.
3.) Why do they use the probability?
A: Performance. On a higher volume server you don't want the garbage collector
running on every request of session_start(). It will slow down the server
needlessly. So depending on your server volume, you may want to increase
or decrease the probability that the garbage collector runs.
I hope that this ties things together for you. If you're like me and you tried
session.gc_maxlifetime and it didn't seem to work (because you tried it
out on a development server so as not to disturb anyone), then this post
hopefully saved you some head scratching.
Good luck!
Each time session_start is called the session files timestamp (if it exists) gets updated, which is used to calculated if session.gc_maxlifetime has been exceeded.
More importantly you can't depend on a session to expire after session.gc_maxlifetime time has been exceeded.
PHP runs garbage collection on expired sessions after the current session is loaded and by using session.gc_probability and session.gc_divisor it calculates the probability that garbage collection will run. By default its a 1% probability.
If you have a low number of visitors there is a probability that an inactive user could access a session that should have expired and been deleted. If this is important to you will need to store a timestamp in the session and calculate how log a user has been inactive.
This example replaces session_start and enforces a timeout:
function my_session_start($timeout = 1440) {
ini_set('session.gc_maxlifetime', $timeout);
session_start();
if (isset($_SESSION['timeout_idle']) && $_SESSION['timeout_idle'] < time()) {
session_destroy();
session_start();
session_regenerate_id();
$_SESSION = array();
}
$_SESSION['timeout_idle'] = time() + $timeout;
}
session.gc_maxlifetime is based off of the last time a session file was modified. So every time a session file is modified or a session_start() is called in a separate page, the countdown to gc_maxlifetime begins anew and the user stays "logged in". This is the value you are looking for. You can modify this through ini_set() in your php files, or edit php.ini if you have access to it
session_cache_expire() only controls the HTTP "Expires" header. This header controls how long the downloaded page contents stay in the user's browser cache.
To check the current values, this code will be helpful:
$gc_maxlifetime = ini_get('session.gc_maxlifetime');
$gc_probability = ini_get('session.gc_probability');
$gc_divisor = ini_get('session.gc_divisor');