ryan77 — 2012-02-01T03:38:58-05:00 — #1
I have an application that ideally should allow the user to log in and leave open until they either log out or close the browser. (I'm curious as to how facebook and others actually do this.) I understand how to set the timeout value for the gc_maxlifetime in the php.ini file and have done so. It's my understanding that when this timeout value is reached, the session variables will be wiped out. I'm currently using sessions and can live with the max timeout for now.
In my application after the time value has been reached and the user tries to use one of the features, the application appears to hang up because the session variables referred to are gone. According to the error.log, my $_SESSION['loggedIn'] variable is undefined. That makes sense and it would appear that I need to code to redirect the user to the login page. But when you refresh the window, the application fires back up and functions normally thereafter without having to log back in. And that's my confusion. How is this possible if the session variables are gone? I confirm that the PHPSESSID cookie still exists, but if the session variables are undefined...
Anyway, I'm at a loss. I've been reading up on the session cookie as well as gc_maxlifetime in both the forum and from outside sources. Before I implement a solution that, though not facebook-like yet, will get the task off my ToDo list, I'd like to understand what's going on here. If the user really has to log back in after the gc_maxlifetime count occurs, I can code for that, but I don't want them to be able to refresh the browser and keep going.
Thoughts, suggestions or direction on where to go for this info would be greatly appreciated.
ryan77 — 2012-02-01T15:45:08-05:00 — #2
Here's the condensed version of what I'm trying to relate above:
A user logs into my application. After the session times out on the server, the application no longer works. The session variables are undefined. This has to do with gc_maxlifetime. I understand all of this and there is no problem here.
Then the user refreshes the browser and the application begins working again. All the session variables are set without having to log in again. This has to do with the session cookie on the user's browser. I do not understand what's going on here.
scallioxtx — 2012-02-02T14:19:41-05:00 — #3
The value for gc_maxlifetime does not mean "after this many seconds the session will be invalid and destroyed", but rather
-- http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime (emphasis is mine)
So every time PHP starts processing a request there is a chance it will invalidate and destroy current sessions older than gc_maxlifetime. By default this chance is 1%
As for your question how facebook and others keep people logged in, they usually set an extra cookie which identifies the person logged in, and if they see there is no user logged in they check if that cookie exists and if so try logging the user in using that cookie. So that cookie is kind of like the username and password of the user (without actually storing the username and password as that would be a HUGE security risk).
This is the only way (at least that I know of) to keep a user logged in when he closes and re-opens his browser. For more info on this search for "php persist login" in your favorite search engine.
To avoid getting out while the browser is open there is an alternative option where you just send a simple Ajax request to the server at a set interval (say every minute) that prolongs the lifetime of the session. That way the session will not expire regardless of how long the user is idle.
ryan77 — 2012-02-02T23:47:34-05:00 — #4
I've begun looking into your suggestions. Thank you. And thanks for the clarification on what's actually happening with the garbage collector.
What still confuses me is that after the session variables have been cleaned up by the garbage collector (and I'm able to confirm this in the error log) and I'm no longer able to access the features of the application, if -- with the application still frozen up -- I click the refresh button of the browser window, the page refreshes and the application becomes functional once again.
I must be missing something in my understanding because to me the session variables appear to be getting repopulated with values (login and password because each page requires this confirmation) but I didn't log in again. I just hit the refresh button. Thoughts on that?
scallioxtx — 2012-02-03T03:28:04-05:00 — #5
Are you using any framework? If you are, maybe it uses the cookies I described in my previous post?
ryan77 — 2012-02-03T03:52:35-05:00 — #6
No framework. Just me and TextMate...completely SitePoint (Yank) indoctrinated. And the only cookie is the session cookie.
scallioxtx — 2012-02-03T05:03:40-05:00 — #7
That is very weird indeed I don't know how that could happen :-/
ryan77 — 2012-02-03T12:30:14-05:00 — #8
Well, you've given me some good info. Thanks. I just hope I'm not leaving out a key piece of the puzzle in trying to explain what's occurring. I'm only now starting to delve into understanding the server setting and their implications. Will keep at it and hopefully come up with something to explain all of this.