I have two users who joins a MediaMode::ROUTED Session. Both users PUBLISHES their cameras and microphones and SUBSCRIBES to the corresponding PUBLISHED video feed. I'm building a web app that can be used for communication using your Opentok.js.
My current JavaScript codes follows the idea of the AutomaticReconnection (discussed on this URL: https://tokbox.com/developer/guides/connect-session/js/#automatic_reconnection).
Note that the users who are testing my codes are in different countries (e.g. in Amsterdam - Netherlands and in the Philippines). Neither of the users triggers the 'disconnect()' method of the Session - we have a "STOP" button that triggers the 'disconnect()' Session method. And with several tests that we did, the test users' Session always gets the 'clientDisconnected' event. I have used Tokbox Session Inspector and it has been consistent that I see 'clientDisconnected' as the cause of our Session disconnection.
Based on the documentation:
"clientDisconnected" — A client disconnected from the session by calling the disconnect() method of the Session object or by closing the browser. ( See Session.disconnect().)
Why do our test users always get 'clientDisconnected' with my MediaMode::ROUTED session?
What could be the possible cause of this?
Regards,
It's hard to explain this behaviour without more information such as the code you use to connect/publish/subscribe.
It may be easier if you create a TokBox support ticket at https://support.tokbox.com/hc/en-us/requests/new and include the relevant session ID and connection IDs so the server side logs can be examined.
Related
I am setting up an application with realtime events using nchan (https://github.com/slact/nchan). The application itself is built on the Laravel framework. However, for now everyone that subscripes to specific sub-channel will get new events as soon infomation is pushed to the corresponing pub-channel.
I want to limit that so only logged in users should be able to subscribe to events. Hence, if I am not logged in, it should not be possible to create a websocket and listen for events from for example http://www.example.com/chat/pubchat?id=some_id.
Is there any way to make this possible?
As far as I know, I cannot use Nginx/Nchan to make database queries to get only logged on users that way. And Laravel itself cannot limit subscribers since that is handled by Nginx/Nchan (but on the other side, can make database queries).
Thanks for any tips!
EDIT: Seems that I might can use the Drizzle module (https://github.com/openresty/drizzle-nginx-module) and use the session ID as identifier. So if that ID is not present in the session table the connection will be blocked.
I have a Slack command bot that posts ephemeral messages and lets the user decide whether they want to make the message visible to everyone else in the channel ('Send') or delete the message ('Cancel'). Since Slack API doesn't provide the original message when user interacts with an ephemeral message, I have to store original messages in Redis, retrieve them when user interacts with the posted message and delete the key from Redis afterwards. The one thing I'm worried about is clogging up Redis with keys that will never be deleted because user never interacts with the message (in other words, doesn't tap on any of the buttons, just leaves the message as is and walks away).
Does Slack API provide any way of knowing when ephemeral messages get deleted so I can clean up Redis? Or is there a better way to solve this problem in general?
No - Slack has no mechanism to inform your app when an ephemeral message vanished. In general they will live until the user refreshes the page on his browser (in the web version).
But I can offer an alternative solution to storing all messages on redis:
Since you created the initial ephemeral message you should be able to always recreate that same message later if you know the exact functional context (e.g. User ID).
All you need to do is to store an ID linking to its context in the buttons of your first message. If the user clicks on the buttons the Slack request will include those IDs, which allows you to identify its context, e.g. take the proper action or recreate the same message for sending to the whole channel.
You can use the name or value field of an action for storing IDs. (See also this answer.)
That ID can either represent the instance of an object (e.g. a customer), so you can fetch that object from your DB again or it can be the ID of your server session, which enables you to work with server session and keep all the context data in the server session. (see also this answer).
I'm trying to figure out how Websockets works. I read some articles, tutorials, etc and I have a pretty basic understanding of how it works, but there is one element that I can't understand how to implement.
My idea is the following : One user will load a "customer" page containing all informations of that customer + a discussion thread. If an other user load that same page, they will be able to discuss in real time and if one user update the data of the customer, the second one will see the update.
The thing that is bugging me, is how can I allow users to access a customer data, but by checking that they can access it (for example, users can access the customer of their group, not all customers)
How can I be sure that the current user will access a customer he has the right (in the websocket)?
Thank you for your help!
Think of the websocket connection itself as a separate thing. A socket used by a client can subscribe to many different events.
What you're describing is topics. When the websocket connection is established, you send a message using whatever socket framework you're using to subscribe to a topic. For example, it could be a topic called customer-123. (A analogy for a topic, is a chat room)
Your application logic (server side) will verify that the currently logged in user has permission to access customer 123, and if so, permits them to join this topic. If you don't do this, it would be trivial for users to listen to any messages relating to any data.
Whenever a user updates any data that is relevant to customer 123, a message is posted to that topic. And thus, any user who is in that topic will receive the message.
An socket might subscribe to many many topics for each customer they open in your app. And topics can be combined and managed in groups depending on how you want to send messages.
In a typical large app, it's common to have a websocket subscribe to topics like user-123, team-456 by default so the server can send messages to them individually or to the entire team to which they are a member of.
For example, if a user updates customer-123, I might send a full data object to the customer-123 topic, and if customer 123 belongs to team-456, I would also send a small notification object like 'User 789 has updated customer 123' to the entire team (which is what powers Facebooks feed like system).
As your app grows, you'll use services like notification hubs to manage the fact that there could be thousands of topics each with thousands of subscribers.
The best thing to do is share a session ID and set up authentication token policies between your web application and your socket session. You could set up your own policy middleware to check the session ID.
You aren't really clear about how you're trying to accomplish this. If you're using express/socket.io, you can use this module: https://www.npmjs.com/package/express-socket.io-session
Hope this helps!
Like any other production application, you need authentication (who is allowed to use the app) and authorization (what functionality can a authenticated user perform). Authorization (ie, access control - ACL) is probably more precisely what you are looking for. Your app has to consult an authorization subsystem to see if the current user has access permission to edit/view another user's information.
This is not a trivial concern for many applications; security and privacy are important aspects of any web-based (distributed) application.
I'm working on a real-time chat. I need to change statuses of the room owner and connected users, together with the UI. Since NodeJS/SocketJS/etc don't guarantee message delivery, I switched to pure Ajax for that.
The system works like that:
- User presses a button to change his status
- An Ajax request is being sent to the server, and a status change request is being saved in the queue in DB
- Users send Ajax heartbeats every second. On the server this heartbeat function also processes the queue (when sent by the room owner). Besides it sends the current statuses of users in the room in response every time.
The issue is: there might be temporary internet problems on both sides, which causes all kinds of problems. This happens due to the fact, that the heartbeat Ajax requests are being processed in an arbitrary order on the server, or the responses are being received in a wrong order on the client side. As a result users have wrong data about current statuses and the UI changes are also wrong.
What is the best approach when making a system like that? What am I doing wrong or how can I fix the issues above?
Thank you!
Have a look at Max's blog a Django-Realtime-Chat and how he does it.
I have a problem with the way sessions and conversations are handled in Seam. We have some rather long forms where most of the time you start filling in the first screen and then some actions are executed in the background and the users leave the computer to do some work, and then later they come back and annotate the work.
Problem is that most of the time the sessions time out or the conversations timed out. While the second one can be easily fixed by splitting the workflow, the first is more important, since the user has to log back in, navigate to the right screen and only then can enter the annotation.
Is there a simple way to have a snippet of Ajax that would trigger a refresh of the session in the background. This would allow us to keep the sessions alive indefinitely.
Also is there an easy way to keep conversations alive?
Are you using RichFaces? We use something like this to keep the session alive.
<a4j:poll interval="10000" reRender="form1" action="#{logger.userIsAlive}" />
The "action" attribute is optional, we use it to keep a record of the connected users. We don't use conversations but I would say that this would also keep the conversation alive.
If you are not using RichFaces, then you could use an AJAX framework like JQuery to ping the server by calling a Servlet for example.