I was wondering if I could determine if someone's session has been ended and if I could do something if it has.
So for example, if session has ended set player status to offline.
If a user does not make a request to the server you cannot reliably know when their session has ended unless you use a database system. For example, you have a sessions table:
session_id | user_id | session_start_time
Whenever you load a page you look if a session_start_time is old enough to be deleted. For example:
if (($data['session_start_time'] + USER_SESSION_TTL) < time()) {
// delete row
}
USER_SESSION_TTL is the time that the user's session stays alive if he is inactive.
Now if the user does not have a session associated with him, you can safely assume he is offline. I generalized a bit, but it can be applied to many systems.
Hope this helps
There is no built in mechanism for this, though, if you implement your own session handler, you can probably do something about it.
See http://nl2.php.net/manual/en/function.session-set-save-handler.php for some ideas.
Related
I want to add a "close other active sessions" button to my PHP web app.
I'm thinking of tracking (userid,sessionid,expiration) on a MySQL table and kill the sessions the following way:
$currentsessionid=session_id();
foreach($othersessions as $session){
sessionid($session['sessionid']);
session_start();
session_destroy();
}
mysql_query("DELETE FROM sessions WHERE userid = $currentuserid AND sessionid <> $currentsessionid");
session_id($currentsessionid);
session_start();
The table would also be updated after each session_start() if the user is logged, removing expired entries.
Expired entries are removed every time a user logs in.
Is this the proper approach? Any suggestions?
In PHP the sessions are normally isolated. You need to create your own session handler and write session (plus some extra tracking information) into the database so this become more easy to manage.
For example, like you have in your question, the userid. You then can search for sessions of a specific user.
Another field you should have is a timestamp so that you can let sessions expire, e.g. if older than X hours, you throw them away.
You can - if you like - also take a look if a user has got an existing session and import the old session. However this can have security implications. You need to think about what happens when an attacker logs on instead of the real user.
Can an attacker even throw the valid user out of the system then? That should be prevented.
Also take into consideration that you can take over the session data of a previous session under a new session ID. That is similar to session_regenerate_id(), a login should always regenerate the session id, as well as the logout and other, important steps (e.g. re-authentication before changing the email-address).
Hey, I'm trying to get my php website to basically "log out" (session_destroy()) when the same user logs in somewhere else. Is there a way to do this? To remotely destroy a specific session?
Thank guys!
Scott
It's certainly possible, using session_id. When the user logs in somewhere else, you can do this step before starting a new session for the new login:
// The hard part: find out what $old_session_id is
session_id($old_session_id);
session_start();
session_destroy();
// Now proceed to create a new session for the new login
This will destroy the old session on the server side, so when the other computer accesses your application again it will try to access a non-existent session and a new one will be created for it (in which the user is not logged in anymore).
The hard part is finding out what is the ID of the "old" session. There's no one-size-fits-all way of doing that; you need to have some mechanism in place to be able to tell that the session with id XXX belongs to the same user who is logging in now. If you are using database sessions this should be easy enough.
It's not necessary to create your own session handlers.
Simply store the session ID with the username in the database upon login.
Every time the user fetches a page, compare that user's session ID with the stored session ID.
If the session IDs don't match, it means the user has logged in somewhere else, and you should self-destruct.
I can imagine you could do this by using your own session handling. If you store you sessions in database, you could delete them from other app, if you needed to. You would identify the user by user name or something like that.
The best way is to create your own session handlers, if you have full control over how the sessions are stored/retrieved and controlled it's not that difficult to force a log out and it offers you a whole broad range of useful features. If you've got time.
But, for a quicker solution: Store the session ID from PHP in the database with the user, and check this in your isLoggedIn function - or whatever you use. If it doesn't match, force the logout.
Another thing you could do besides Jon's answer (which is great, +1), is initially check where the user came from (referer) and destroy the session if the user comes from another webpage than your own.
$referer = $_SERVER['HTTP_REFERER'];
$referer = parse_url($referer);
if($referer['host'] != "yoursite.com" || $referer['host'] != "www.yoursite.com") {
session_destroy();
}
source
I would like to suggest that what we can do is, get the time and add some addtional value (like manu1234567) and store in database when user log's in .
add that in session also.
now on each page compare both , and if that is equal then proceed , else forward to another page or give some msg .
now other part
when ever another user will login with same username and password, database will update
and for first person there will be error msg "some one logged in from some where else."
Note : time will always different . so there will be very very less chances that two values will be same.
I'm having a small bit of doubts here as to how sessions should be handled.
Right now, I have a MySQL database where the "users" table has a field for session_id. If NULL, the user is not logged in? If the value is the same as the value of the PHPSESSID cookie, than the user is logged in.
I don't know why, but I somehow feel this isn't good enough a way to make sure which user I'm dealing with. Is there something I'm missing, or do my fears hold no ground?
There's nothing essentially wrong with what you describe as far as I can see.
Of course, your login and logout mechanisms need to reliably add and remove the user ID when logging in or out. (insert a user name only when passwords match, etc) . Also, expired sessions need to be removed reliably. If that is given, this should be fine.
Just an extension on what Pekka said, you could also include a 'last seen' field into your table and use that as a judge because as Pekka mentioned about expired sessions, your database won't be informed that they are gone. So you will be forced to either make something so it manually checks the last time a user was there or something along those lines and then map that back to the session timeout (which I believe is either 15-30 minutes by default for PHP) and then after said amount of time, clear any of the users who haven't been active within the last X minutes.
A thought of the options above - tracking a user in the user table would only allow 1 session per user. I suggest storing the data in a table called sessions and have these columns:
sess_id | sess_userid | sess_ipv4 | sess_lastseen(datetime/timestamp) | sess_sessionid (varchar)
I believe that will allow user to have multiple logins, but with different session id's, even if they share the same public IP, allowing a laptop, tablet, phone etc - this way u can track each device separately from a single user.
hope this helps!
Another post ir read last week suggested having a prevsession and currsession and making sure u are assigning a new session (every 15 mins?) to the correct user. . swapping the sessions from old to new and storing the prev session as a check - not sure if this would help but thought id mention it.
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
}
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.