php observer pattern to log user out when session times out - php

I'm trying to log users out when the user's session timeout happens. Logging users out - in my case - requires modifying the user's "online" status in a database.
I was thinking that I might be able to use the observer pattern to make something that would monitor the state of the user session and trigger a callback when the session expires - which would preserve the user's name so we can update the db. I'm not exactly sure where to begin on the session side. Can I tie a callback to the session's timeout?
are these things built into any available pear or zend session packages? I will use whatever I have to to make this happen!
UPDATE # 16:33:
What if you have a system where users can interact with each other (but they can only interact with online users)? The user needs to know which other users are online currently.
If we simply check to see if the session is still alive on each page refresh, then after a timeout, the user is sent to a non-logged in page, but they are still listed as online in the system.
That method would be fine except that when we timeout the session, we lose the information about the user which could be used to log them out.
UPDATE #16:56:
right. Thanks. I agree...sort of ugly. I already have some slow polling of the server happening, so it would be quite easy to implement that method. It just seems like such a useful feature for a session handling package. Zend and PEAR both have session packages.

Take the simplest case first. Suppose you have 1 user on your system, and you want their session to timeout, and you want accurate reporting of their status. The user has not been to a page in 12 minutes, and your session timeout is set to 10 minutes. One of two things will happen. Either they will visit again in a short while, or they will not. If they don't visit again, how will the system ever run code to update their timeout status? The only way* is to have a separate process initiate a status update function for all users who are currently in status "in session".
Every time a user hits your site, update a variable in the database that relates their session to the last accessed time. Then create a cron job that runs every minute. It calls a simple function to check session statuses. Any sessions older than the timeout period are set to status "timed out". (You should also clean up the table after timed out sessions have sat for a while). If you ever want a report on the number of people logged in, query for all records that have a last accessed time later than the timeout interval start.
"*" There are other ways, but for the purposes of a simple web application, it's not really necessary. If you have something more complex than a simple web app, update your question to reflect the specific need.

Whenever a user hits a page, mark that time in the database, call this column LastAccessed. When the user clicks on the Logout portion of your site, you can set this value to null. When writing your query to find a list of users who are currently logged in, do the following:
SELECT * FROM Users WHERE LoggedIn=1 AND LastAccess > DATEADD(Minute,-20.GETDATE())
Which would return the users who still have an active session. Pardon the SQL which probably doesn't work with MySQL/PHP, but this should give you a general idea.

Why do you want to do this? The common approach is to check on every request sent by the user if the timeout has expired. Of course that means that the status in your db is not up to date, because the user is still shown as logged in, even though the timeout has been reached.
But for practical purposes that usually doesn't matter.

Ugly but maybe workable suggestion:
Add an asynchronous keep-alive requester to pages, that updates their last-active timestamp. You can then have a cron job that marks users as offline if they have a last-active timestamp more than 20 seconds old. Setting that cron job to run every minute would do the trick. I'm not sure there's a way to trigger something to happen when a user's session times-out, or closes their browser.

My first thought is that you could create a custom session handler that interprets being logged in as having an active session.
For some examples on creating a custom session handler see http://www.daniweb.com/code/snippet43.html and read the PHP doc http://ca.php.net/manual/en/function.session-set-save-handler.php

I know this might be a older question but the "best" answer to your question is found here:
http://www.codeguru.com/forum/archive/index.php/t-372050.html
Here is what it says:
The php.ini file contains a setting called sesison.save_path, this determines where PHP puts files which contain the session data. Once a session has become stale, it will be deleted by PHP during the next garbage collection. Hence, a test for the presence of a fiel for that session should be adequate to determine whether the session is still valid.
$session_id = 'session_id';
$save_path = ini_get('session.save_path');
if (! $save_path) {
$save_path = '.'; // if this vlaue is blank, it defaults to the current directory
}
if (file_exists($save_path . '/sess_' $session_id)) {
unlink($session_id); // or whatever your file is called
}

Related

update `last_active` on every request

I am making a single session application as in only one session is allowed for each user account at some specific time. In the process, I think I need to update the database EVERYTIME the user send a request to the server to update the last_active value. This value would later be used when another user tries to login with the same account somewhere else. If the last_active is still too close, I will not allow the login. But if the previous logged in user is inactive (as in not sending request to the server) after a 15 or so minutes, I will let the new logged in user in and kick the previous one.
I was just wondering, if this method would put too many load on the server or not.
If you have a root access, you can store the last active, unique session id , and other stuff on memory related storage like redis,APC,memcached.
If you using codeigniter, take a look at this
me personally, using php fastcache library, you can also see the usage in this site
It depends on your server how soon your server process a request if it can not able to handle frequent request this result your server might be stop for sometime.
Solution:
Better use cache tool like "Redis".

How to get notified about a closed session in PHP

I am keeping a list of active users of my web site.
When user logs in I add them to the list.
Then I periodically (on timer) call a PHP script which delays PHP session expiration time on the server each time by 10 mins.
When users logs out I remove them from the active users list.
As timer is stopped and an expiration is not delayed anymore, a PHP session expires after 10 mins.
So far so good.
When user closes a browser without logging out, their session still expires after 10 mins as a time stamp is not updated anymore.
But this user still remains in my active users list !!
How can I remove this user?
I am keeping this list in order to prevent users from entering from 2 computers simultaneously, that is a client requirement.
EDIT:
I am sure that this can be done as bank sites, ticket sites etc. somehow cope with this problem.
The simple answer is you can't. Not with PHP alone anyway. If you are happy to force javascript usage, you could write a script which would 'poll' the server from the user's browser on very regular intervals to let it know the user was still active.. you would then also reduce the interval set for your PHP script to keep things updated with more accuracy.
You could try updating the "active users" list on a more frequent basis, but it would generally make more sense to clear a user's session data upon each login. Therefore, if a second login occurs from another computer, the first one is terminated upon the next page load.

Logout issues in a single-user system

I've been asked to build a project management application that could only host one user at a time. I managed to do that by simply creating a status row in my user table which is set to 1 when somebody is logged in.
Now, status = 1, nobody else can log in, they get an error message instead saying that another user is already using the application. When the online user logs out, I update the status row in the database and set it to 0 in order to allow other users to log in freely.
Everything is working just fine except, as you can see, it relies on the logout button and many users forget to logout that way, they just close the tab or the browser leaving status as 1 and then blocking the whole system.
I tried a few methods to update the database on page close with session timeout or via onunload but I couldn't reach a clean and reliable way of doing so.
How could I develop such a system combining single-user mode and auto/smart logout at the same time?
Thanks for your help.
The only way you can achieve this is by checking whether the logged in user has been active in the last X minutes. Check this when the new user tries to log in. When the previous user has been inactive for that period, unset the status in the database and let the new user in. You should then also invalidate the session of the previous user, in case he comes back.
Don't try to detect session endings.
You could reduce the user's Session timeout. I think you can accomplish that both from Php and the Webserver (Apache, IIS, ..), should really look at the man pages. That done, you could realize a polling system which periodically ping the user to verify his/her presence. For example, you could make a client-side Ajax script which pings the site at fixed intervals, so that would prolong the user's active Session. If the user doesn't ping the site anymore, after the time-window has expired, then set his/her status = 0.
That is just an idea. Try searching more about on Google.
A variant: you could set a cookie from the server-side language, and associate the session with that cookie. So, give it a short expire time. Then make a client script which periodically send a hidden request to the server. When the server receives the request, it re-write the cookie again, so the new time will start again from the beginning.

How to retrieve logout time

I have built a simple cakephp app with simple user authentication. It works. I have a problem when the user is idle for longtime, the app logs out the user. The user should log back to perform actions on the app.
My question is there is anyway I can save the time when the user was logged out.
I appreciate any help.
Thanks.
Ivanka,
what Thariama wrote seems to be quite sound. Nevertheless, if you need the feature to show the user status to others, imho you have to work with cron jobs and cake shells.
You would need:
Thariama's suggestion with the timestamps
The cake shell + cron job going over every logged in user. Once NOW - lastActionTimeStamp > maxIdleTime, log user out and persist timestamp.
Adding the second point has the benefit that other users do not see the logged out one as present/active, as it could be the case if you stick with 1. alone.
Depending on the size of your userbase, you can set the checking interval.
Another approach could be to implement some kind of client side timer (JS/AJAX) triggering a logout, which could be unreliable in nature, but should be even easier to implement.
My 2 cents.
On your server/application there will be a configuration setting which defines the idle time span after which a user gets logged out. With this knowlege (i am sure you know where to look) you are able to ddo the following
$time_span_to_logout_user = 600; // example 10 minutes
Everytime a user is logged in and requests one of your websites pages you simply store this timestamp into the db.
To get to know the loggout time you simply take this timestamp from the DB and add the $time_span_to_logout_user -> this is the user loggout time.
You can set it on app/config/core.php:
Configure::write('Session.timeout', '120');
Documentation explains this variable depends on security level.
Yes, write your own session handler and log the time using the gc and destroy fns

What is the best way to deal with sessions when the user may stay logged in, but a session key needs to be updated, because of another update?

I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.
Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.
How do you deal with this?
A few ideas that I have are:
After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.
Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)
Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.
For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).
Are there other better methods?
--
Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.
I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.
Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.
I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.
Regards
I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).
this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.
Normally you should do 2), but you don't like it.
maybe you can use sessions stored in db.
when a user change his name, put into all sessions from that user the information "refresh userdata".
on the next request the userdata is reloaded again into the session and is cached there.
this can be done be reusing your loaduserdata function which called at login.
php session_set_save_handler() - also read comments
php session_decode() - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.
[edit]
don't forget:
when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.

Categories