So I made a swift chat app that first requests a php file to load older messages from the mysql adatbase, and then I set up the real time chat with socket.io
Whenever a user sends a message it requests a php file which checks if the text is valid, then I do the encryption and store the new message in encrypted version in the database and I send the original message with socket.io to the correct user
What would be a good way to store user datas that are changing? (Nickname, profile picture)
The current swift array that holds the messages inself looks like this:
....| chatRooms
........| chatRoomId
........| messages(array)
............| userId
............| message
It would not be a good idea to store the nicknames with the messages I know, because the messages are getting cached and if the user quits & reloads the app, the cached nickname will show for older messages and the new one for the new messages.
Maybe I should make a userData array in the chatRooms? Or outside it? And save all the current talking-to user ids inside it then every minute request a PHP file to load nicknames?
What do you suggest guys?
Since you are already using an userId it would be obvious you need a new entity Users with the ID, nickname, profile picture etc...
If your objective is to limit queryes and load new profiles only when needed then you could broadcast a message from the server indicating which userId has changed data, since you are using websockets. This is to avoid reloading all the data every time (the problem is of course the profile pictures)
Related
Goal:- Inserting messages in faster way to database.
I have integrated xmpp openfire one-to-one chat over my website.
I am using Monitoring Service plugin for storing messages into the database.
What i am facing is when user send a message from one user to another user at that time messages are stored in the database.
Now messages are stored, but i am facing issue of inserting messages late into the database.
I am loading messages via ajax call when user clicks on another user message thread but if the messages does not store in the database ofcourse it will not be returned in ajax call history.
I have done following configuration settings for Monitoring Service plugin.
I've find alternative solution of modifying Monitoring Service plugin's jar file and decrements inserting seconds but ultimately it will affect database.
Eg. Every minute 50 users send 10 messages at that time database may hanged.
Any help would be appreciated if i can store the messages into the database as faster way!
So I want to develop a chat system based on nodejs and socket.io, I have made a prototype and it works, the only thing that is stuck in my mind is how to store the chat messages in the database.
I guess is not a good idea to store a message when a user hits the enter button, because this is live chat you could have 1000 just from a user in 30-60 min.
The question is WHEN to store the data in the database, because I don't think that storing right away when the user hits enter will work on the long term?
The chat works on the same idea as facebook.
If you are not saving the messages at the moment, how do you plan to save them when you want to?
The messages sent have been delivered to the client and your server no longer has them, and you can't use the client to store them in a database.
You need to store the messages as the user sends them.
Basically I have a chat, using AJAX, PHP.
I let guests login by filling their name and clicking login.
It fills the session $_SESSION['guest'].
Now, when they close their browsers, or something, once the session ends, I want it to say in the chat
"The username has left the chat".
But I am not sure on how would I do this.
Any ways to do it? Maybe I could fill an array of users that were active in the past 5 minutes, if not, remove from the array and it will kick them off the chat.
Any ideas?
You could have an array of users in the backend with the timestamp of the last ping.
Then, the clients end can update the backend using ajax by sending a new timestamp every so many seconds.
Whilst your backend is being updated by one of the users, your backend can do a check on all users checking the last timestamp sent to the current time, if its over 2 minutes or something you can tell they have left the chat and output the message.
Without a direct connection to the browser, you won't be able to actively tell if they're connected. I'd suggest a ping-like solution, requiring the browser to ping the server every n seconds to keep the chat "alive".
If the browser doesn't "check in" with the server, the server assumes they've disconnected and reports back to the other participant.
That said, if you're able to dive a little deeper, Google "javascript real-time chat" and you'll have several paths to success.
Add a jQuery .unload() event to your chat client. When they navigate away from the chat it will be fired and you can use it to send the last bit of data to display that message.
Here is the documentation: Link.
Example:
$(window).unload(function() {
//send message to server informing it of client leaving
});
I have a working php application in which I want to add real-time support. I would like to use nodejs/socket.io to add that kind of functionality.
First problem I found was how to properly authorize user on nodejs side (user is already authenticated on php backend through PHP session). Using socket.handshake.header.cookie on nodejs side i can parse and get PHP session id, which I can authenticate through redis/memcache/database (depending on what have I used to save session information). Everything looks cool when user has only one tab/window of the site opened - when having more and using session_regenerate_id(), in nodejs the user authenticates with another sessionid key, so I cannot distinguish two tabs by anything other than the socket id they connected with. When user logouts he shouldn't be getting any messages on any tab (because he already logged out on every tab/window from that browser). So on logout message (sent from browser just before the logout PHP things) I should remove all the socket connections connected to the authorized user id. But what if user logges in on two devices (fe. pc browser and an ipad safaris). After logout on one device, he shouldn't be getting any messages on the device he logged out, not on every device. How can i distinguish connections from different devices/browsers in socket.io? Of course not using session_regenerate_id() would be efficent here, but what can I do if I really want to use this feature?
Another problem I have is rather a security issue (or even question). Let's assume that authorized user in application can see page example.com/user1 (which is a news feed for user1) and cannot see example.com/user2 (fe. he doesn't have rights to see it). I'd like socket.io to send update messages to browser when user is on example.com/user1, and of course not to send when user is on example.com/user2 site. On socket.io side I can read the referer address (so presumably, when user is on user2 site he does not get any socket.io connection). The question is: should I compare the referer address with the rights of authenticated user on node.js side? Or maybe the referer value is safe on the node.js side? Adding another db check on node.js side would slow it down (because almost every request there should be same database check on two sides - PHP and node.js).
Or maybe the whole concept of socket.io + PHP application working the way I presented is wrong?
UPDATE
I think I found a way to omit problems with the first question - basically I just add another cookie (besides PHPSESSID) fe. named NODESESSID, which I generate (fe. using uniqid()) when user is authorized. Now authorization on node.js side is comparing PHPSESSID and NODESESSID (both must match). Now, when user logges out he delivers the message logout to socket.io and socket.io disconnects all the sockets with NODESESSID. This is like connecting the benefits of regenerating session id and not regenerating session id (but is not vulnerable to session fixation, isn't it?).
For your second questions:
the Referer is not secure, as mentioned in the comments.
I hava a similar problem in my application and this is how it works for me.
first, i hava a single-page app where all traffic goes through the socket, but thats not necessary. it should work with sessions the way you managed it, too.
in nodejs onConnect I ask the backend if the user is authenticated and then store the userid into the socket object (socket.data) and also populate a hashmap to lookup sockets from userids directly.
second, i use Redis and subscribe to a redis list from nodejs (see redis pub/sub). the php backend pushes messages in this list with a userid to address the message. nodejs takes this message (e.g. a new news feed item), looks up the userid in the mentioned hashmap and sends it to the client. so, a user only gets what he is authorized for. the client then decides what to do with the message. if the user is on his feed page, it could add the item. if the user is on someone elses feed, it could simply add a notification somewhere else on the page. it might also discard it.
on the php backend site, this messages are send to redis everytime an event occurs which needs to be shown live on some connected client. if user1 posts on user2's feed, the new item is stored in the database and in the same time is send as message into the redis queue.
this system also helps to reduce DB load since nodejs just need to query a database to make sure the connected user is already authenticated.
Actually, you can avoid using node.js, and use phpdaemon, its written with php and work very good.
I want to build a simple message system between my users of my website. For that i constructed table for messages as below:
tbl_messages
-pk id int
-fk sender_id int
-fk receiver_id int
-is_read boolean
-send_date datetime
When a user has my site opened in the browser and some other user sends him message, i want to send a notification message to the receiver user (something like 1 new message or (3)Messages) while the page of receiver is opened.
Eg: facebook notification, stackoverflow notification comes when new comment arrives
I performed such action by making a javascript function to be called every 2 min. This function makes an ajax request to output the notification. I wonder is this the correct and effective way to do because i have to perform the sql query every 2 min and if there are lots of records in my table, such action will create more load on database.
What other solutions can I perform instead of this?
If you correctly indexed your database and designed your program, it shouldn't be a problem.
You won't be able to design a notification system as responsive as Facebook and other, since it's almost impossible to create push systems with PHP.
If you have a dedicated/virtualized server (and not shared hosting), look into things such as NodeJS.