Setting login expiration to one week

[Vahrokh Vain]

Hello,

I have found a lot of more or less outdated documentation about F3 sessions, cookies and so on.

I'd like to ask what steps I should follow, with current F3 stable version, to do this:

1) User logs in.
2) User gets "something" set (in a cookie? In JAR? I don't understand) so that his logged on status lasts for a week.
3) If he logs in within a week, then the cookie / session / whatever lifetime has to be extended by a week.
4) If he won't log in within a week, then he loses logged on status. He's thus forced to log in again in case he returns back to the website.
5) If he has to log on (more than a week passed) but less than one month passed, then he should pick up his stored session, that is, session should not be destroyed after a week.
6) If he won't log in within a month, he also loses his session.


How would achieve that with F3? I am not asking actual code (if it's too long to type it), but for the F3 objects I should set and how.


Thanks in advance.

[ved]

Hi there,

There's nothing about your required behavior that's specific to F3.

You can achieve what you want using sessions, cookies and probably some sort of timestamp on your users database to keep track of the visitors last active date.

I recommend you make use of F3's database session handler because it's probably easier to deal with the sessions on the database than normal file based sessions.

Remember to make sure that the server/php doesn't do any session garbage collection because that will probably mess up your desired results (especially the keeping the session stored for a month part).

Steps 1-4 can be accomplished by using some kind of functionality like a "Remember Me" cookie which you can find tons of tutorials and docs on the web.

As for the resuming session part, during login you'll have to do some checks to see if the last session_id that the visitor used is still on the database and resume the session with that id instead of creating a new one.

[Vahrokh Vain]

Hello, Ved,

I am already using the DB F3 session object.

What I am trying to do, is to use F3's facilities, not "general PHP" ones. I have noticed that if I mix handmade session stuff with F3's, it's going to get messy, raise errors because F3 expects to manage session's function calls by itself and so on.
Therefore I'd like to use "JAR" and F3's cookie facilities to manage this stuff, however there are no real and up-to-date examples of this.

[ved]

Well, F3 syncs all global variables with the framework itself, so calling $f3->set('SESSION.something', 'value') is the same as $_SESSION['something'] = 'value' and vice-versa. The same goes for cookies, get and post.

The JAR array is basically just a shortcut for "session_set_cookie_params()" and in it you can setup the cookie's domain, lifetime, path, httponly, etc. That alone will not allow you to do what you want.

Start by creating a login with "Remember Me" functionality. This is basically just a cookie you set on the client and then evaluate it when the client returns in order to see if you can log him in automatically or not.

Then, when evaluating the "remember me" cookie, you'll have to write some custom code to compare a (for example) "last_active" date with the current date. If it's longer than X, then destroy the stored session and redirect to login. If not, then just resume your stored session. Your app should take care of updating the "last_active" record on every request in order to keep it updated. (unless you only want to take into account the time since last login, which I doubt it because the visitor can be logged in for days)

Don't focus on using F3 for this since it doesn't have that functionality baked in. Sure, you can use F3 to set and get cookies, sessions etc, but the rest of the checks and behavior you'll have to code in plain php on your auth controller/method/helper.

[ikkez]

Well I think using DB managed sessions only give you the advantage of having a better control of invalidating specific user sessions, simply by erasing them manually, and that your sessions do not mess up with other session data that might be produced and stored in the global /tmp dir on the server all together. Despite of that, sessions do behave the same... there should be no need to look things up from that db table manually.

when you log in a user, set a simple session var, like $f3->set('SESSION.is_logged_in',true);
depending on your servers php.ini settings, the session cookie is now active for a given time. It depends A) on session.gc_maxlifetime which tells php how long the session is hold active between user interactions before the garbage collector cleans the file (db entry), and B) the session.cookie_lifetime which tells the users browser how long to store that session cookie in the browser.

I think the default settings in php are 1440 seconds for gc_maxlifetime (24min) and 0 (seconds) for cookie_lifetime, which usually means, it's wiped when you restart your browser (depends on the browser).
For that cookie thing you can use the handy JAR var to set an expiration time. i.e.: $f3->set('JAR.expire', time() + (60*60*24*7)); // 7 days
F3 expects a timestamp here.

nevertheless, you should increase session.gc_maxlifetime either in the php.ini or with ini_set("session.gc_maxlifetime", 60*60*24*30); or something like that.

The remember me function could simply be a trigger to set a different JAR.expire time. So the browser invalidates the cookie much faster then it would when the remember me checkbox is on.
Just remember to set the JAR settings before you create / use the SESSION.

[Vahrokh Vain]

Thank you, Ved and Ikkez, you really gave me a good direction!