Session timeout
sheldonlg
in order to preserve session variables. I do not have access to the
php.ini.
I added a line at the beginning of each file (they all have
session_start) that was:
ini_set("session.gc_maxlifetime", 60*60);
but it didn't help. I brought up a page and it had the session
variable. I then let that screen sit for a half hour (1/2 the setting)
and when I refreshed the page the session variable was gone.
A phpinfo yields session.gc_maxlifetime=1440. If I run the file that
"sets" it at 3600, and then run phpinfo, it still shows 1440 for both
the local and master values.
Any ideas anyone?
Jerry Stuckle
Try "3600" instead of 60*60. The second parameter to ini_set is a
string, not an integer.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
sheldonlg
> sheldonlg wrote:
>> I am having a problem with session timeouts. I need the session going
>> in order to preserve session variables. I do not have access to the
>> php.ini.
>>
>> I added a line at the beginning of each file (they all have
>> session_start) that was:
>>
>> ini_set("session.gc_maxlifetime", 60*60);
>>
>> but it didn't help. I brought up a page and it had the session
>> variable. I then let that screen sit for a half hour (1/2 the
>> setting) and when I refreshed the page the session variable was gone.
>>
>> A phpinfo yields session.gc_maxlifetime=1440. If I run the file that
>> "sets" it at 3600, and then run phpinfo, it still shows 1440 for both
>> the local and master values.
>>
>> Any ideas anyone?
>>
>
> Try "3600" instead of 60*60. The second parameter to ini_set is a
> string, not an integer.
>
Thanks. I'll try that. I used that one because that was what I found
on the net. Anyway, I just made the change and have to wait an hour.
However, I am not optimistic because phpinfo still gives 1440 for both
local and max.
Jerry Stuckle
It could be your hosting company isn't allowing the override of the
lifetime.
But this is not a global change; the parameter needs to be set in every
page which uses sessions. Try a file with just:
<?php
ini_set('session.gc_maxlifetime', '3600');
phpinfo();
?>
See if the local lifetime changes.
sheldonlg
That is exactly what I have been doing by way of an included file on
every page. For my test here I did my login page where I create the
session variable and then went to a page where I use it. It worked and
was there. That was at 10:33. I left the page just sitting there. If
the new timeout doesn't work, then at 10:57 it should timeout and if I
refresh the page the variable should be gone. I am going to wait until
11:05 and try it. I will report later on the result.
sheldonlg
It is 11:05. It didn't work.
Jerry Stuckle
Did you call ini_set() before session_start() (or any other session
functions)?
And did you try the code I showed you above to see what the new local
value is?
sheldonlg
I tried both before AND after.
>
> And did you try the code I showed you above to see what the new local
> value is?
I hadn't, but I did now. It shows the new local value as 3600. However,
it times out at the old value of 1440. Maybe the system only uses the
lesser of the local value and the preset maximum value?
Jerry Stuckle
But are you doing this for ALL sessions? Because if there are multiple
sessions using the same directory, the shortest one rules.
Or, are you sharing the session directory with other users on a shared
host? Their setting can override yours, also, then. If so, set you
session.save_path.
This is all very clearly indicated in the manual under Session Handling
Functions.
Darko
Maybe shanemayer42 was right when writing a comment in the
http://www.php.net/session user contributed notes, on 19-Aug-2000
07:11, saying:
Session Garbage Collection Observation:
------
It appears that session file garbage collection occurs AFTER the
current session is loaded.
This means that:
even if session.gc_maxlifetime = 1 second,
if someone starts a session A and no one starts a session for an
hour, that person can reconnect to session A and all of their
previous session values will be available (That is, session A will not
be cleaned up even though it is older than gc_maxlifetime)."
------
Haven't tried, but maybe he was right.
sheldonlg
it from scratch and it is not yet released. Yes, it is on a shared
host, but the session is uniquely named. I will set the
session.save_path to a unique area and see what happens.
Jerry Stuckle
It doesn't matter what the name of the session is. What matters is the
save path.
sheldonlg
Well, thanks, that worked. Actually, too well. It doesn't time out
1440. In fact, it didn't even time out at 3600. .....but I can live
with that.
Jerry Stuckle
There's no guarantee the session will be cleaned up at 3600 (or
whatever). The only guarantee is that it will not be cleaned up before
that.
It all depends on when the garbage collector runs.