I have my sessions stored in a database, thus I thought the problem was there, but have come to realise,
that is how sessions behave naturally.
I originally thought, that the expired session garbage collection dumps stale sessions, if the user is away after the default 24 minutes.
But in my case, it does, but since the user still has a valid session cookie containing valid data, the session is brought back from the dead even if
hours has passed, and the browser hasn't closed. Not desirable for me.
As Tom pointed out to me, (which I haven't gotten around to do as yet) in not so many words ->
1. When the user logs in assign a session variable to lets say time() + 600 (10 mins in the future).
2. Each page load, refresh the session variable in step 1 *if* the session variable references a future timestamp.
3. If on a page load, the session variable references a past (older than time() - 600) timestamp, core dump the session data -> $_SESSION = array(); to /dev/null, hell, whatever makes you happy...
Although I haven't gotten around to using these steps, it seems like it would work for what Im trying to achieve.
John W. Holmes wrote:
No question :)Okay. I think I thought you were the original poster. How do you know
It's just that this is what the original question was about and why I
suggested
doing his own sesssion timeout check as the deleting proccess is too
unreliable
to depend on for timeout handling. PHP will quite happily return stale
data
which could be bad in a login type of situation.
it's returning "stale" data, though? If the cookie is valid, and there
is still a session file (or data in memory), then why is it stale or
expired. Maybe I'm just missing something here. If it's expired because
you think it's too old, then you track your own timestamps and do your
own cleanup. Is that what you're saying?
---John Holmes...
-- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
