I'm trying to write a simple web chat app with PHP and AJAX.
I need to be aware of all the open sessions so that I can display a list of online users that are available to talk to. I also need to be aware of log outs because I use "both the sending and the receiving party are offline" as a condition for considering a chat session terminated and deleting the messages.
I'm keeping track of logged in users in a database: adding an entry on log-in and removing it on log-out works fine, but it's not comprehensive, as there are two other ways a user can become logged out:
server side session expires after inactivity.
client side cookie gets destroyed on browser close. Seems like a bad idea to use some sort of onclose triggered AJAX (what if the browser crashes or something?).
Simplest solution seems to be keeping a timestamp of last activity. I see some problems with this though:
AFAIK server-side expiry is chance based, so it wouldn't be accurate (and if I get the expiry time 3 minutes wrong, that's 3 minutes where some guy could be talking to an offline user wondering why no one is answering)
I'd have to constantly be querying the database to check every logged in users' last activity time compared to the current time. I don't see when / where I'd do this efficiently. It seems stupid to do this every single time the list of online users is needed.
Any help appreciated. I'm coding this myself because I'm not aware of any web chat frameworks that can integrate with my existing user database, do correct me if I'm wrong.
I don't think you're going to be able to do much to mitigate the constant querying to determine if users have logged off by closing the browser, internet connection issues, etc., but you could perhaps have each client make an AJAX request to the server every 5 seconds to update the last activity time, and have your application on the server consider the user "logged off" if they have missed 3-4 consecutive requests (ie, their last activity time is > 20 seconds).
On the client side, you could then check the last activity time every time your client sends a message to another user, and respond that they'd logged off if that had happened. If they attemped to open a chat with another user, you could also do an immediate call to check their status. Then you could perhaps check the status of all users in the user list every 30 seconds. That way your client gets pretty quick feedback if the person (s)he is chatting with drops offline unexpectedly.
You could invert your pattern, replacing your Ajax pull behavior with a push notification system.
In this way you can notify your chat users in realtime of login and logout of new chat members. I never did something like this in practice, but I've read about this kind of technology and it seems very interesting for cases like yours.
It's just a little bit harder than the ajax pull way, but once the main structure is implemented you can add functionality easily and the performance would be a lot better.
Some links I found that can be useful:
http://www.pubnub.com/blog/build-real-time-web-apps-easy
http://www.ape-project.org/
This is a railscast episode which deal with a javascript chat, the implementation is in rails, but even if you don't understand rails you should be able to follow it to get the core concepts: http://railscasts.com/episodes/260-messaging-with-faye
I'm not sure if you need both probability and divisor but here's what I do to auto logout people:
ini_set('session.gc_maxlifetime',3600); // 1 hour
ini_set('session.gc_probability',1); // it does garbage cleaning EVERY time
ini_set('session.gc_divisor',1); // it does garbage cleaning EVERY time
session_start();
Most of the data you are currently using and the data you need is stored in the PHP session - it's just not obvious how to derive the user id from the information.
If you switch to using a database bound session handler then it all becomes very easy. I had a quick google - and there are lots of examples out there. but a lot of them (e.g. this one) don't check for expiry on reading back the session. OTOH the example I've linked to does show adding the user id to the sesion record - which you'll need later. So the session read handler function should be something like:
read:
SELECT session_data, username
FROM sessions
WHERE session_id=' . session_id() . '
AND last_updated>= ' . date('YmdHis', time()-ini_get('session.gc_maxlifetime'))
And to get all the currently logged on users:
SELECT username
FROM sessions
WHERE last_updated>= ' . date('YmdHis', time()-ini_get('session.gc_maxlifetime'))
...and let the (overridden) session garbage collector automatically clear out redundant data.
HTH
First separate your concerns.
As far as 'list of online users' is concerned,you can use database & it seems you already have figured that out. (even if some one doesn't logs out properly,displaying a few extra online users won't do much damage)
Now for the chat app,for checking if a user is still online you will have to use ajax.
There is simply no other way.Of course there always can be a hack,I don't know.
see the image when you answer here (stackoverflow).it constantly checks if time has passed(& have you typed anything new) & saves a copy.
It seems that you are most concerned about performance and you have the implementation details figured out(mostly). Just change the type of the table that handles sessions to 'memory', this will reduce the performance cost of quering the db for every request to almost nothing as you are fetching data directly from RAM. Just make sure you delete the session every time a user explicity logs out, or you mark the user as inactive.
But no matter what you do implementing something that requires constant communication between client and server can never be done perfectly over HTTP. But if you put reasonable timeouts etc. it will work 99% of the time.
I am late to this party, but let me give my two cents.
In this particular scenario, there is no need for a push system for bad notifications. There is also no need for cron. Let me explain :
Say A,B and C are in a chat room & B's browser crashes, so his session expires. Right now , the server thinks B is still there but she is not. How do you update A & C? When A & C ASK for the update. Check B's last keepalive timestamp and figure out that their session has expired.
If all A,B & C crash, then this never happens I hear you ask. Who cares? There is no one to see our mistake now! The only downside is keeping up their chatroom alive which costs some database space. This can be cleaned up when another chat session is created.
A final gist :
Keep timestamps for the last time an action was taken.
Use a user event to loop through timestamps and take out the deadwood.
In case of users, this would be logging them out. In case of chatrooms, this would be those that have expired.
Related
I've been reading up on (mysql) triggers the last few days... specifically what I'm trying to do is figure out a good methodology for updating a user's information.
The case use for this is related to a user management system:
Take for instance a admin user updating a regular user to a manager, this user type change would then enable|disable software features on the interface.
Problem:
You won't know about this user type change unless you query the database and reset say for example the $_SESSION['user']['type'] variable, and or the user logs-in|out of the system.
Question: Is there any good methodologies to solve this headache?
I don't think mysql triggers would be ideal for this. Why? Because you will most probably end up with part of logic in php and part in mysql. It's a good thing to stay with one technology because it will be easier to maintain/debug code for you and your colleagues later.
So in your case, if you want the change of user role would take immediate action, you would have to either load user role on each script run or log out user using some flag in database that would signal that his session is not valid anymore (or you could implement your own session_set_save_handler that would save session somewhere in file where you could delete it to log out user).
It depends on your needs which solution would better fits your case.
If your roles logic is complicated and it consists of multiple roles assigned to one user as well as extra permissions assignments/excludes per user it may be better to do this check once on user log in and then just remember the result using session.
If checking for permissions on each script run isn't an issue, you can do it. But be aware, for security reasons, it may be a good practice to force user to log in again.
If the user log out could cause lose of work, you should let user log out itself and apply new permissions after next log in (you can show user a message that new permissions are awaiting log in to take effect).
So it really depends on your needs to choose if it's better to log out user, give him new permissions right away or wait until next log in.
Question: Is there any good methodologies to solve this headache?
Find good reasons not to do it!
While this might sound like a joke, i am completely serious. You have to consider:
What is the value of that feature?
Is it worth the headache cost?
What are the risks of that feature (incomplete work / system consistency)?
Do you have to change the system core?
Would you have to revalidate the system?
Are there other really great features (system improvements) waiting to be implemented?
Someone who doesn't feel comfortable answering these questions doesn't really need that feature.
Find simple alternatives:
Call the user and ask to log out.
Notify the user per email.
Provide a button for email notification.
Send email notification automatically after changing permissions.
This is no laziness. Just focus on real value.
One alternative would be to do ajax requests, with some time interval, that will update your user $_SESSION.
If you have any changes in your 'type', you can do whatever you want, like force user do re-login your application, or do nothing but update $_SESSION information.
Of course, you need to know if you really need to get this information before user logout and login next time, with updated profile.
I think storing your session into caching mechanism like Redis would give you added advantage. It is light weighted than storing session data in database. You can create clusters very easily. Click here to see sample implementation.
So once a user "type" changes, you can load the redis data cache and update it as per your wish.
I think the safest way to do this, and the one that I would choose is the "headache" way.
'regular' user A logs in and opens session A1.
'admin' user upgrades A to a 'manager'.
For now, session A1 is a valid session, but it will not grant the user 'manager' privileges.
When user A logs out and logs back into session A2, this session will now grant the user all the privileges of a 'manager, having looked up the current 'type' from the database.
Alternative that may be slightly expensive depending on your application:
Every time a user presents a session token, use the database to check against the validity of the session. If that session has invalid info (ie. the 'type' no longer matches) then force the user to log back in again.
Adding another alternative:
Don't use a MYSQL trigger, when the application caller (the admin) updates User A's 'type', it also makes a call to wherever you're caching the sessions and either (a) updates the session (inadvisable*) or (b) renders the session invalid and forces the user to log in again.
*Note that all of these solutions require the user to re-enter their credentials after they have new-found 'manager' power before they have access to the 'manager stuff'. I think this is a safer practice than updating the session without any authentication.
My recommended methodology would be to store the type of each user in the database. The problems that would arise if you decided to store the type as a session variable would be (among others):
Once the session expires, this information would be lost. Usually sessions last 30 minutes, though you could modify this to be as long as you want. However if you create a session that lasts 1 month, then anyone who has access to that users computer would be logged into the users account without needing to use any password.
You would be unable to use powerful and advances queries offered by databases (like MySQL for instance which uses SQL). If you store your information in sessions, sure you can find a way to look up each users information 1 by 1, but why reinvent the wheel? It is not easy developing a database structure from scratch, so I wouldn't recommend doing it.
Regarding your concerns on accessing a database once the information has been updated, I wouldn't say this information is as concerning as you might believe it to be. Lets imagine the following examples:
1)
If a user for instance is a manager currently and loads a website where he can do powerful actions, and right afterwards he is demoted to being a normal user, then having this information in the database would work perfectly. If the user tries to use his powers (that are no longer his), he would click a button that would send an a request to the database to confirm his type. Database queries are very fast, so speed is not an issue. I would be more concerned of the speed it takes for you to obtain information from a session variable than from the database.
2)
If the user was on a page while he was a normal user, and while on the page he became a manager, then he would be able to exercise his powers after refreshing the page. I mean if you used sessions and you wanted to have the page obtain the information automatically with something like AJAX and then update his options on the page, that would consume much more server power than a simple refresh.
To give a simple SELECT * FROM myTable WHERE id = 4 can take as little as 1 millisecond to be executed on a database. Databases have been especially designed for their speed which is why they are prefered
HOWEVER, maybe you don't have access to a database and that is why you are searching for an alternative? Well you are in luck! MySQLi is a database which only uses a file to store the information. It was especially designed for users that don't have much resources, and has many of the capabilities as MySQL would have.
Since every user has a role or type it means that the ability of viewing or editing content in your application is solidly connected to this factor. This means that the 2 basic things that your session variables should have are userID and userType which you should also store in your database
These pieces of information can be passed to $_SESSION['user'] for example as a small array where your array key can be the userID and the userType the value.
$_SESSION['user']=array($userID => $userType);
Once a user login your initial values are stored to session. In order for your application to know what userA can view or edit in your application, you basically run a comparison in your script against the userType that userA has. But to achieve what you want you basically need to re-fetch the piece of information in the beginning of every VIEW/PAGE of your application. If new userType has been assigned to userA simply show a message that he/she will log out automatically in 15 seconds (give time to read the message itself) in order for the changes to take effect. While your user sees this message you take the current session data he/she may have and save it in database, since some session variables might be (or not) available in a upgrade or downgrade of userType. By placing the comparison of the userType in the beginning of each VIEW/PAGE of your application you save yourself of the headache that a user can loose data.
If your scripts use $_SESSION['user']['type'] to know about the user's privileges, I would just change its value.
Or perhaps I didn't understand the issue ?
I have developed a website in which server side coding is done through PHP and I am using MySQL database. There is a specific page on my site that should be opened only once at a time, that is, if it is opened by one person at the same time, the second person should get a message "This page is opened by someone, you can't use it at this time" I thought of a logic that I store timestamp in the database and compare the time from the database and if it's same as that time then it means the page is opened by the other person so access should be restricted. But I don't find this logic reliable. Could there be any other logic that could be implemented?
Obviously this is quite an open question and impossible to give a complete solution to without actually seeing your database/code.
However, here would be a pretty stable logic:
User attempts to access current page.
1) PHP checks DB if session_on_page is not Y.
1a) If Y: Error Message, page in use.
1b) If not Y allow user to access and set session_on_page_user to the users login id or username etc.
2) On page load, start AJAX session that re-logs Y every 5 seconds along with current username.
2.1) Using JavaScript, check for onunload and run a AJAX function that sets session_on_page to N and also wipes session_on_page_user.
That process will be fine if it's simply for viewing data. If there's also any forms/edits being made whilst on the page I would suggest hashing the current time along with user name to create a fairly secure hashkey that is unique to that user and compare it against server time when performing any updates. You may want to go even more secure than this depending on your case scenario. You could use PHP sessions to double check also and potentially even some Apache handling.
Like I said, it's quite a broad question so we can only really give suggestions to logic.
I'm doing research on internet behavior. The participants of my study are asked to fill in a questionnaire.
What they don't know is that this questionnaire consists of an infinite series of forms:
whenever they submit one form, they are presented with another one. From their perspective, the questionnaire never ends. It is filled from an array containing thousands of random questions from old studies.
I want to test, how long different users keep going.
I have two options:
Save each form to the database, when it is submitted. Each successive form UPDATEs the same data record with the current page count. This is easy, and I know how to do it.
No data is saved while the user performs the task. The current page count is saved from the SESSION, when the user abandons the task, i.e. when he closes the browser window.
How do I do this? How can I tell PHP to save a $_SESSION variable, when the user closes the browser? Is this even possible in a reliable way, i.e. the solution does not rely on functionality that is not available in all browsers, such as onbeforeunload (which does not work in Opera)?
$_SESSION is profoundly unfit for the task you want to perform. It is designed (and works well enough) as a vehicle to introduce state into an application relying on the stateless HTTP protocol, not to do something on the absence of further HTTP requests.
When relying on a server-sided mechanism, one of the main points to consider is, that session cleanup can happen concurrently, which is not a problem for dumb destruction of a session, but will hand you problems if you want to do something else.
Relying on client-sided code is much worse: What if the user doesn't close the browser, but it crashes? Or the user is on mobile and drives into a tunnel?
My recommendation would be, to understand, that your problem at hand is not one of session keeping, but one of analytics. This would argue heavily into inserting one row per page into a database:
Do your analytics a posteriori: Are you sure, you already know all questions, you want to ask? Only raw data is able to allow you to change or append to your research problem.
Including a timestamp in the rows will allow you to ask for correlation between response time and total time ... was the user doing your survey just as a side-distraction or was he concentrated on it?
Basically you create a specialized log, that can be analyzed by lots of tools - it being in the DB making it easier to query it.
What I do now is save the current state of the session into a database with session_encode() after each form is sent. Before I show any user any page, I check if there is a session with isset($_SESSION['whatever']). If there is none, I check in the database, if a session was stored for this user (they are identified through a login, all this takes place on a site that requires registration). If a session was stored, I drag it from the database and resore it with session_decode(). If there is none, I create a new one. Now, when the browser was closed, the user gets returned to the last page with all variables (of all previous pages) prefilled, including current error messages ("Please choose ..."), if there where any.
I have made a simple chat application in PHP/Ajax/MySQL.
I am regularly calling these two methods-
setInterval("GetChatParticipants()",5000);
setInterval("GetChatMessages()",1000);
Now as per client design, there's no Logout or Sign Out button, so I want to detect when user closes the browser and at that time I have to delete the participant record from the database. I dont want to use onbeforeunload as Chrome refuses to accept Ajax requests on window unload event.
So I am thinking of implementing in Ajax by making repeated reqests. But the question is how exactly shall I do that. Shall I update the Participant table with last_active_time and if the difference between current time and that last_active_time is , say, more than 10 min, then I should delete the user? Is it a practical solution or could there be a better one?
You have the best solution IMO. In Javascript create a "ping" function that pings every minute / two minutes etc with a session ID unique to that browser/session. Have a sessions table on your server and update when you get a ping. Have another script that looks for entries that have not been pinged for long periods and close the sessions.
I've had this structure running for thousands of concurrent users on one site, and I had to drop the ping down from 1 minute to every 2 minutes when load got heavyish (that was on 2 load balanced servers while running the rest of the site too). Obviously you make your ping approx 45% of the time-out time (so if one fails, a second should hit). It's a simple process that can handle the load.
Edit: don't use "setInterval" for the ping, but user "setTimeout" when each ping either returns or fails. Otherwise, with setInterval, if your server gets too loaded then the pings queue, never respond and queue some more. You get a meltdown of the server as all server sockets are used, then you can't connect by ssh to fix it... not a moment I was proud of.
Yes it is practical solution and then only one you can rely on, so, no matter what else you use in addition to that, this one final check should be in your logic at all times. Said that, combining several methods will give you more possibilities to detect user leaving early. Add onbeforeunload for browsers that support it. Add "log out" button for clients coming from insecure location that want to log out right now when leaving PC and finally, check for inactivity.
Yes, it is practical solultion. The only difference is where to store information about user ping. You can do it in database or in key-value storage like memcached. I prefer the second one as I think it takes lesser resources.
I've a particularly long operation that is going to get run when a
user presses a button on an interface and I'm wondering what would be the best
way to indicate this back to the client.
The operation is populating a fact table for a number of years worth of data
which will take roughly 20 minutes so I'm not intending the interface to be
synchronous. Even though it is generating large quantities of data server side,
I'd still like everything to remain responsive since the data for the month the
user is currently viewing will be updated fairly quickly which isn't a problem.
I thought about setting a session variable after the operation has completed
and polling for that session variable. Is this a feasible way to do such a
thing? However, I'm particularly concerned
about the user navigating away/closing their browser and then all status
about the long running job is lost.
Would it be better to perhaps insert a record somewhere lodging the processing record when it has started and finished. Then create some other sort of interface so the user (or users) can monitor the jobs that are currently executing/finished/failed?
Has anyone any resources I could look at?
How'd you do it?
The server side portion of code should spawn or communicate with a process that lives outside the web server. Using web page code to run tasks that should be handled by a daemon is just sloppy work.
You can't expect them to hang around for 20 minutes. Even the most cooperative users in the world are bound to go off and do something else, forget, and close the window. Allowing such long connection times screws up any chance of a sensible HTTP timeout and leaves you open to trivial DOS too.
As Spencer suggests, use the first request to start a process which is independent of the http request, pass an id back in the AJAX response, store the id in the session or in a DB against that user, or whatever you want. The user can then do whatever they want and it won't interrupt the task. The id can be used to poll for status. If you save it to a DB, the user can log off, clear their cookies, and when they log back in you will still be able to retrieve the status of the task.
Session are not that realible, I would probably design some sort of tasks list. So I can keep records of tasks per user. With this design I will be able to show "done" tasks, to keep user aware.
Also I will move long operation out of the worker process. This is required because web-servers could be restrated.
And, yes, I will request status every dozens of seconds from server with ajax calls.
You can have JS timer that periodically pings your server to see if any jobs are done. If user goes away and comes back you restart the timer. When job is done you indicate that to the user so they can click on the link and open the report (I would not recommend forcefully load something though it can be done)
From my experience the best way to do this is saving on the server side which reports are running for each users, and their statuses. The client would then poll this status periodically.
Basically, instead of checkStatusOf(int session), have the client ask the server of getRunningJobsFor(int userId) returning all running jobs and statuses.