Re: [PHP] Sessions not destroyed
As Marek has stated a number of times, the session options in php.ini are meant to be set to reasonable values for the usage pattern for your server, in order that you can achieve a balance between a /tmp or /var/tmp of several zillion kilobytes, and a constant 100% cpu usage as the gc routine runs again and again. That's all it is. If you wish to time out your sessions for security purposes, you need to handle that security in your application. Security is the responsibility of the developer, and should always remain that way. Anything else is leaving you open to trouble. To restate, the session.gc_maxlifetime defines how long the session must have been inactive in order for it to be SAFE to be gc'ed. That's why it's session.*GC*_maxlifetime and not session.security_maxlifetime. The setting has no bearing on when a session MUST be gc'ed. That is up to the developer to deal with - hell, with session.gc_divisor = 0, you can have session files which are never deleted if you desire - that doesn't mean your users should never be logged out, now does it? Hope this clears things up a little. Cheers Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
There is a difference between the session file existing, and the user still having a valid session. If the timeout has occurred, and the file has not been deleted, when the user accesses it, the session will not show up in $_SESS[]. Which for all intents an purposes, means the session has been deleted as far as the script is concerned.. Now whether it gets deleted by such a direct request, I wonder. It will get deleted by OTHER sessions be requested, if the gc probablity works at that moment. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
M. Sokolewicz wrote: Hendrik Schmieder wrote: Ok, I think you're all missing a few points here... First of all, every time a session is started/accessed/written to/whatever, PHP makes a check, it calculates , using gc_probability/gc_divisor, if it should run the gc (Garbage Collector) on this call or not. If it should, then it checks which sessions are expired, and those that are, are deleted. If the one the user just activated was one of those, then the session is reinstated, as a NEW (blank) session. The reason for the gc being called with a CHANCE is that when you have 50 people/min visiting your site (that's a bit less than 1 hit/sec), you're calling the Grabage Collector once EVERY SECOND. The garbage collector is pretty slow, especially when many sessions are open, because it needs a lot of filesystem info. So, instead of calling it with every hit, it's called less, only gc_probability/gc_divisor of those times. The Garbage collector works on ACCESS TIMES for files, so if you have a sessions lifetime of 5 min, and someone revisits in 4 min. Then the session will last at LEAST another 5 min (and theoretically more as long as the garbage collector isn't ran). Imagine our situation again. If you have 1hit/sec, and gc_probability=1 and gc_divisor=100, then these are the chances the GC hasn't been run yet: 1 sec: 99% 2 secs: 98.01% 3 secs: 97.0299% 4 secs: 96.059601% 5 secs: 95.09900499% ... 10 secs: 90.438207500880449001% ... 20 secs: ?? ... 30 secs: 73.970037338828042273001509231671% ... 40 secs: 66.897175856968051393833859880371% ... 50 secs: 60.500606713753665044791996801256% ... 60 secs: 54.715664239076147619474137084001% So, after 1 min, you have a 50% chance that the GC has been called at LEAST once. This is a logaritmic equation (1-1/100)^n (n being the amount of secs; making log(n/100)/log(99/100) = secs (n being the chance you want in percent)). This means that after 7 min 38, you have only a 1% chance left that the GC hasn't been ran yet! After 1 hour, this is as far down as 0.019% !! Right, back to the point. The higher the hitrate, the lower a gc_probability you need to get the garbage collected regularly. Doubling the amount of users means that you'll have the same chance in a bit LESS than half that time aswell. Now, in your case, only 1 user every HOUR visits... this means your garbage is collected really really sparsely! Setting a high divisor and probability would be useful for you :) Ok, so far so good, now the reason why sessions aren't removed automatically without the need to visit the site. The reason is very simple. PHP works as a "daemon" type of application. It does not, and can not, run on its own initiative :) It either runs all the time, or it does not run till someone starts it. Having a continuous PHP app running in the background is not very efficient, and thus the only (easy) way to get it to be cleaned is to do it when PHP is running, and thus when a user visits the server. Please note, it doesn't matter what SITE the user visits for the gc to be ran!! As long as the php engine used is the same on the same machine ;) (and a session is started/written to/called/whatever). Ok, after that long explenation (which hopefully everyone could follow), I still wouldn't know the answer to the original question (*sighs*). Oh well... If you mean question of the OP, the answer is in your first mistake: > If the one the user just activated was one of those, then the session is > reinstated, as a NEW (blank) session. No, the session persists with the old data. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Hendrik Schmieder wrote: Graham Cossey schrieb: [snip] If you are right, then this is a severe design bug. Depends on your point of view. It is a sideeffect of loading current session (and thus accessing it) before the session gc is called. So the question is, should the session module give up on current session just because it should have been garbaged, even if the session file still exists? Apologies if I'm way off here, but I'm relatively new to PHP. Surely it should be down to settings in php.ini, not a point of view or the probability of the garbage collection possibly having run when a new session is started. Why can there not be a session_timeout value that is adhered to? Would it not also save everyone from writing their own code to determine whether or not they should be using the session that PHP is making available? If my site is accessed by few users and I have a session 'timeout' of 30minutes specified, if Bob leaves his PC at 10:00 I would expect that if he returned at 10:40, and no-one else had accessed the system, his session would have expired and he would need to re-authenticate to create a new session. Short of writing custom session handlers, the current arrangement seems somewhat haphazard to me. Those are my current thoughts anyway. Graham Graham, that's also my point. Unfortunately this isn't happening. Bob can work on as he never left his PC. Hendrik Ok, I think you're all missing a few points here... First of all, every time a session is started/accessed/written to/whatever, PHP makes a check, it calculates , using gc_probability/gc_divisor, if it should run the gc (Garbage Collector) on this call or not. If it should, then it checks which sessions are expired, and those that are, are deleted. If the one the user just activated was one of those, then the session is reinstated, as a NEW (blank) session. The reason for the gc being called with a CHANCE is that when you have 50 people/min visiting your site (that's a bit less than 1 hit/sec), you're calling the Grabage Collector once EVERY SECOND. The garbage collector is pretty slow, especially when many sessions are open, because it needs a lot of filesystem info. So, instead of calling it with every hit, it's called less, only gc_probability/gc_divisor of those times. The Garbage collector works on ACCESS TIMES for files, so if you have a sessions lifetime of 5 min, and someone revisits in 4 min. Then the session will last at LEAST another 5 min (and theoretically more as long as the garbage collector isn't ran). Imagine our situation again. If you have 1hit/sec, and gc_probability=1 and gc_divisor=100, then these are the chances the GC hasn't been run yet: 1 sec: 99% 2 secs: 98.01% 3 secs: 97.0299% 4 secs: 96.059601% 5 secs: 95.09900499% ... 10 secs: 90.438207500880449001% ... 20 secs: ?? ... 30 secs: 73.970037338828042273001509231671% ... 40 secs: 66.897175856968051393833859880371% ... 50 secs: 60.500606713753665044791996801256% ... 60 secs: 54.715664239076147619474137084001% So, after 1 min, you have a 50% chance that the GC has been called at LEAST once. This is a logaritmic equation (1-1/100)^n (n being the amount of secs; making log(n/100)/log(99/100) = secs (n being the chance you want in percent)). This means that after 7 min 38, you have only a 1% chance left that the GC hasn't been ran yet! After 1 hour, this is as far down as 0.019% !! Right, back to the point. The higher the hitrate, the lower a gc_probability you need to get the garbage collected regularly. Doubling the amount of users means that you'll have the same chance in a bit LESS than half that time aswell. Now, in your case, only 1 user every HOUR visits... this means your garbage is collected really really sparsely! Setting a high divisor and probability would be useful for you :) Ok, so far so good, now the reason why sessions aren't removed automatically without the need to visit the site. The reason is very simple. PHP works as a "daemon" type of application. It does not, and can not, run on its own initiative :) It either runs all the time, or it does not run till someone starts it. Having a continuous PHP app running in the background is not very efficient, and thus the only (easy) way to get it to be cleaned is to do it when PHP is running, and thus when a user visits the server. Please note, it doesn't matter what SITE the user visits for the gc to be ran!! As long as the php engine used is the same on the same machine ;) (and a session is started/written to/called/whatever). Ok, after that long explenation (which hopefully everyone could follow), I still wouldn't know the answer to the original question (*sighs*). Oh well... - Tul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Hendrik Schmieder wrote: Marek Kilimajer schrieb: Hendrik Schmieder wrote: Anyway , if the apache service is stopped (I am not speaking about a crash) all session files must be deleted. Why? Why should users loose their sessions just because I need to restart web server? OK, good point. So I redrew the request for deleting, when Apache is stopping , but not the other point. Your php code is a workaround, but no real solution . Once again, the session timeout was never ment to be a security feature, it is merely a way to not choke the server with dead session files. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Marek Kilimajer schrieb: Hendrik Schmieder wrote: Anyway , if the apache service is stopped (I am not speaking about a crash) all session files must be deleted. Why? Why should users loose their sessions just because I need to restart web server? OK, good point. So I redrew the request for deleting, when Apache is stopping , but not the other point. Your php code is a workaround, but no real solution . Hendrik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Hendrik Schmieder wrote: Anyway , if the apache service is stopped (I am not speaking about a crash) all session files must be deleted. Why? Why should users loose their sessions just because I need to restart web server? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Graham Cossey schrieb: [snip] If you are right, then this is a severe design bug. Depends on your point of view. It is a sideeffect of loading current session (and thus accessing it) before the session gc is called. So the question is, should the session module give up on current session just because it should have been garbaged, even if the session file still exists? Apologies if I'm way off here, but I'm relatively new to PHP. Surely it should be down to settings in php.ini, not a point of view or the probability of the garbage collection possibly having run when a new session is started. Why can there not be a session_timeout value that is adhered to? Would it not also save everyone from writing their own code to determine whether or not they should be using the session that PHP is making available? If my site is accessed by few users and I have a session 'timeout' of 30minutes specified, if Bob leaves his PC at 10:00 I would expect that if he returned at 10:40, and no-one else had accessed the system, his session would have expired and he would need to re-authenticate to create a new session. Short of writing custom session handlers, the current arrangement seems somewhat haphazard to me. Those are my current thoughts anyway. Graham Graham, that's also my point. Unfortunately this isn't happening. Bob can work on as he never left his PC. Hendrik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Marek Kilimajer schrieb: Hendrik Schmieder wrote: Marek Kilimajer schrieb: Hendrik Schmieder wrote: Hello, we have a severe problem with seesions. We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000 In our php.ini we have session.gc_probability = 100 session.gc_dividend= 100 Should be session.gc_divisor OK , changed in php.ini, but no change in behaviour. And you need to start at least one other session so that the first one gets cleared. If you are right, then this is a severe design bug. Depends on your point of view. It is a sideeffect of loading current session (and thus accessing it) before the session gc is called. So the question is, should the session module give up on current session just because it should have been garbaged, even if the session file still exists? That's the point. If the current sesions timed out, since there was no action in the session lifetime, then the session file must be deleted. On the other side, if there's an action in the session lifetime, the timer for this session should be reset to zero. Anyway , if the apache service is stopped (I am not speaking about a crash) all session files must be deleted. Hendrik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Graham Cossey wrote:
[snip]
If you are right, then this is a severe design bug.
Depends on your point of view. It is a sideeffect of loading current
session (and thus accessing it) before the session gc is called.
So the question is, should the session module give up on current session
just because it should have been garbaged, even if the session file
still exists?
Apologies if I'm way off here, but I'm relatively new to PHP.
Surely it should be down to settings in php.ini, not a point of view or the
probability of the garbage collection possibly having run when a new session
is started. Why can there not be a session_timeout value that is adhered to?
Would it not also save everyone from writing their own code to determine
whether or not they should be using the session that PHP is making
available?
If my site is accessed by few users and I have a session 'timeout' of
30minutes specified, if Bob leaves his PC at 10:00 I would expect that if he
returned at 10:40, and no-one else had accessed the system, his session
would have expired and he would need to re-authenticate to create a new
session.
Short of writing custom session handlers, the current arrangement seems
somewhat haphazard to me.
The session timeout was never ment to be security feature, it is merely
a way to not choke the server with dead session files.
If you want a hard timeout, store the last access in session variable:
if(isset($_SESSION['last_access'])
&& $_SESSION['last_access'] < (time() -
ini_get('session.gc_maxlifetime'))) {
session_destroy();
} else {
$_SESSION['last_access'] = time();
}
no need to write custom session handlers
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions not destroyed
[snip] > > > > If you are right, then this is a severe design bug. > > Depends on your point of view. It is a sideeffect of loading current > session (and thus accessing it) before the session gc is called. > > So the question is, should the session module give up on current session > just because it should have been garbaged, even if the session file > still exists? Apologies if I'm way off here, but I'm relatively new to PHP. Surely it should be down to settings in php.ini, not a point of view or the probability of the garbage collection possibly having run when a new session is started. Why can there not be a session_timeout value that is adhered to? Would it not also save everyone from writing their own code to determine whether or not they should be using the session that PHP is making available? If my site is accessed by few users and I have a session 'timeout' of 30minutes specified, if Bob leaves his PC at 10:00 I would expect that if he returned at 10:40, and no-one else had accessed the system, his session would have expired and he would need to re-authenticate to create a new session. Short of writing custom session handlers, the current arrangement seems somewhat haphazard to me. Those are my current thoughts anyway. Graham -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Hendrik Schmieder wrote: Marek Kilimajer schrieb: Hendrik Schmieder wrote: Hello, we have a severe problem with seesions. We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000 In our php.ini we have session.gc_probability = 100 session.gc_dividend= 100 Should be session.gc_divisor OK , changed in php.ini, but no change in behaviour. And you need to start at least one other session so that the first one gets cleared. If you are right, then this is a severe design bug. Depends on your point of view. It is a sideeffect of loading current session (and thus accessing it) before the session gc is called. So the question is, should the session module give up on current session just because it should have been garbaged, even if the session file still exists? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Marek Kilimajer schrieb: Hendrik Schmieder wrote: Hello, we have a severe problem with seesions. We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000 In our php.ini we have session.gc_probability = 100 session.gc_dividend= 100 Should be session.gc_divisor OK , changed in php.ini, but no change in behaviour. And you need to start at least one other session so that the first one gets cleared. If you are right, then this is a severe design bug. with best regards Hendrik Schmieder -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions not destroyed
Hendrik Schmieder wrote: Hello, we have a severe problem with seesions. We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000 In our php.ini we have session.gc_probability = 100 session.gc_dividend= 100 Should be session.gc_divisor. And you need to start at least one other session so that the first one gets cleared. session.gc_maxlifetime = 120 But even after 20 minutes the session file is still there. And the session file ist also not deleted if we then stop the apache service. Has anybody an idea ? TIA Hendrik Schmieder -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Sessions not destroyed
Hello, we have a severe problem with seesions. We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000 In our php.ini we have session.gc_probability = 100 session.gc_dividend= 100 session.gc_maxlifetime = 120 But even after 20 minutes the session file is still there. And the session file ist also not deleted if we then stop the apache service. Has anybody an idea ? TIA Hendrik Schmieder -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
