According to this post at Stack Overflow, the author states that the session garbage collection will only calculate the probability when you explicitly call session_start(); Does this mean even if my session has timed out on the server. Because I don’t call anymore session_start, my session will always be available?
if you’re alone user of your site, session file will be never purged
But. Speaking of session as a mechanism, if you don’t call session_start(), you don’t have access to your session.
Thanks for the answer. So that means any session_start will always calculate the probability and execute garbage collection before use calls right? And say if I set the probability and divisor value to 1 and 100 respectively. Does that mean there a potential possibility of me using my session data 100 times or more after my session data expired and possibly reviving the session data by modifying data? So if I don’t want to access the session data after expiry, I should just set the probability and divisor to 1 and 1?
EDIT: Or does it mean the the garbage collection will do its work 1 in 100 calls even if session has NOT expired?
Oh. You just have to put your hands off these controls.
If you want your sessions work right.
None of these values need to be changed. Defaults are all right.
If you want to access the session data after expiry, you should extend the expiration time.
There are no connection between garbage collection and session expiration. Both runs separately. Garbage collection intended to collect garbage, not active sessions.
Also, you have to understand that session consists not of only session file, but also of session cookie.
Most of time your session get expired because of cookie, not timeout.
Thanks for the answers. But the reason why I asked in depth is because I want to understand how it works in php. Cookies will only erase session upon browser exit, in fact it’s only erasing the association link the browser has to the server. Otherwise session handling is done on the php server side. Under php session settings, there are two variables dictating the garbage collection routine on session variables: session.gc_divisor and session.gc_probability. According to the post I linked in my original post, these two together defines how garbage collection routine acts on the session data. What I didn’t understand was whether or not this routine will activate even if my data is still alive. And what happens after data expires and I modify it again to make it alive.
According to the post I linked in my original post, these two together defines how garbage collection routine acts on the session data.
All I can is only to repeat what I said above.
garbage collection doesn’t affect session data. It acts on garbage. Not data.
Put garbage collection from your mind. You don’t need it in any way.
You can do nothing to your data with gc settings.
The only setting can affect your session data is gc_maxliftime. You can extend session timeout, but I doubt you need more than 24 min of inactivity timeout.
in fact it’s only erasing the association link the browser has to the server
In fact without this link you won’t have access to your session data.
And what happens after data expires and I modify it again
If your data expires, you cannot modify it.
Edit: Just came to my mind
May be the thing you don’t understand is that session file being touched every time when session starts with corresponding identifier. So, as long as you continue visiting pages which contains session_start() call, you prolong your session even without modifying data.
The garbage collection routine always “rolls the garbage collection dice” when session_start() is called, except for when:
initialization errors(you configured php to use different session handler components, and they failed to initialize)
the current instance of the script executing already has an active session(you already called session_start in this page request).
gc routine happens after the session data is loaded. This means that even if the gc runs on this call to session_start, and the session is too old and really should be deleted, it’s too late because it already loaded. It will probably get deleted(from disk, or from db, or memcached…whatever), but it doesn’t matter because the data got loaded into memory already, and will get saved again at the end of the request. So yes, it probably becomes “alive” again depending on what session_save_handler you use(files handler would).
This is why if you don’t want a very old session to get reloaded, you implement the logic in the script, by storing an age variable in the session.
The gc routine really doesn’t care at all about what current session your app might be concerned with. It’s non discriminating, and really is kinda a hack for what would generally be better implemented as a cron job. The files handler literally loops through every file in the directory, and if the filename starts with sess_, and the mtime is too old, it gets deleted. That’s it.
Also, a note on the default files based handler. If you’re on shared hosting, it’s common for everyone on the server to use the same setting for session.save_dir. This means everyone can probably read/write your session files. It also means that, if someone on the server decides to do something like set the gc_probability real high, and set the gc_max_lifetime real low, it will affect your sessions too, because the gc routines that their scripts spawn will operate on the same directory where your files also reside. If you don’t like that, change your session.save_path. But now you need to make sure you adjust gc_probability to a value suitable for your traffic level, because the dice wont be rolling as often if it’s just you rolling the dice.
Thanks crmalibu. I think I understand now, I guess the part that I didn’t understand was that the gc routines occurs for all session data independent of which host the session_start was ran on. I was falsely under the impression that gc routine occurs independently for each user. That’s why I was pondering over the problem a 1/100 chance might cause for session data persistence.
For Shrapnel_N5, maybe I didn’t make it clear. When I said garbage collection, I meant the garbage collection routine that acts on the waste session data (and yes when i said session data, i implied waste session data).
As for the link, what I was interested was how the server handles this garbage collection. Because in fact when I close the browser, the server does not get rid of my session data. I can in fact open the browser again to modify my session id to last session and retrieve the data.
As for session expiry time. It is based on the last change made to session data, not the last call of session_start. If simply a start session is called and data is not touched, the session timer will not reset.
Second one is obvious, I were talking from an average user’s, not a hacker’s point of view.
Last one is wrong, I believe.
To me considering security measures and preventative methods requires me to think from any capable person’s perspective.
Last one is wrong, I believe.
Taken from here.
And from official php site:
Note: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other filesystem where atime tracking is not available. Since PHP 4.2.3 it has used mtime (modified date) instead of atime. So, you won’t have problems with filesystems where atime tracking is not available.
The files handler always writes to the file, whether or not the actual session variables have changed. So, accessing session data through php, results in a file modification.
An exception could be when there’s no data in the session at both read and write times. Writing nothing might not change the mtime of the file. Might be platform specific behavior.
It is about file modification, not session data.
I haven’t seen PHP sources for a long time, but from this comment I merely suppose that since 4.2.3 PHP goes to modify (touch) session file every time session corresponding started.
That does make sense. I just ran a test on my machine too and what Shrapnel said does appear to be right.
Yea, that’s what it appears to be. Sorry I mistook the description.
I know mtime is about modification. But, if you have a zero byte file, and write zero bytes to it, will a files mtime be changed? I bet you that’s platform specific behavior. A session with no data produces an empty string as the data to be written to file.
php doesn’t explicitly call touch()