Currently I'm developing consoles in my webapp displaying user's running *nix application log (game servers) and I just want to make sure that one user can't access other user console by guessing topic name.
I'm using random generated string of 16 chars 0-9, A-Z, a-z, changing on every refresh of page, valid for 30min for each topic name.
Every user of webapp in crossbar config have access to subscribe any topic.
I wanted to set for each user to only subscribe to his/hers console topic but I think that dynamic config for crossbar is not yet implemented.
Is this implementation is enough for privacy of users or it's possible for subscriber to list other subscibers and my work with unique topic names is pointless?
It is indeed possible for subscribers to list other subscribers - via subscription meta-procedures.
Regarding your topic structure - you're doing something like
com.myapp.userlog.user34KUIK567878
com.myapp.userlog.userAHH78738J899
and want to prevent users from being able to subscribe to any channel but their own?
For this you can use a dynamic authorizer - see http://crossbar.io/docs/Authorization/
The dynamic authorizer is called on each subscription (& publish, call, register) request and can then accept or reject this request. It has access to the session data so that you can identify the user.
Related
I want to send message as DM to the users, so I've come with some questions;
1- There are two ways to send DM to the user;
the first one open a conversation with user by using conversation.open, and send message. Then if I want to send the message to the same user, I use conversation.list and find the conversationId by userId, then send message to the same channel again.
Second one is just basically using userId as channelId parameter in chatPostMessageRequest.
I've tried both ways, and both of them are sending message as DM. So, what is the purpose of using conversation.open? I'm asking this because nearly all the answers say you should do this etc.
2- Seems like there is no way to get multiple users by emails except users.list?
3- Also seems like there is no way to send messages to the multiple user at the same time (the content of the messages are different, those are depends on user data).
Sending a direct message by user ID works with chat.postMessage as a convenience, a shortcut. But it's the only method/API that allows you to use a user ID as a channel ID, so Slack warns developers away from relying on it in totality -- if you use conversations.open and the resultant conversation ID, it'll work for other methods like chat.update should you need to edit the message after sending it.
Slack doesn't offer many "lookup" APIs -- most things you'll want to look up require fetching an entire data set (like a list of users with all pages of users.list) and then filtering the results yourself. There are no APIs to look up multiple users at once via email address.
There is also no way to send the same direct message content to multiple users with a single request. In most cases, when an app is sending the same message to multiple users the best practice would be to use a channel to broadcast the message a single time, with the intended recipients as members of the channel.
I want to receive all the events/messages coming and going from all the users to all the channels or other users in a workspace.
There is a way to get messages of a particular user(sending/receiving) by creating an app and using event subscription(https://api.slack.com/apps/A01SP2TL45B/event-subscriptions?).
Is there anything like this available to get all users' events?
There is discovery.user.conversations
This method lists IDs for all conversations (channels and DMs, including public, private, org-wide, and shared) a user is in
I am trying to send messages from several outer sources to a specific channel, which is private and belongs to myself only. The username should be the name of source, not my ID.
I found there are two ways to do such a similar function: Incoming Webhooks and chat.postMessage
I have already practiced these two, which seems no difference between them.
However, in Incoming Webhooks, a statement says:
You can't use Incoming Webhooks with Workspace Apps right now; those
apps can request single channel write access and then use
chat.postMessage in the Web API to post messages, providing very
similar functionality to Incoming Webhooks.
What does it mean?
To my work, which one is better?
with chat.postMessage() you send a message to a specific channel, often you do that in response to a users action. You will need the token to verify the postMessage Request which you receive when the user installs your app.
Incoming webhooks are often used to post general information, e.g. patch notes or general announcements.
As far as I know, you don't need the token since there is a verification behind that Url.
so the webhook url is bound to a specific channel, which is specified through the user. With chat.postMessage you can post messages anywhere (depending on your permissions, maybe not in private channels or direct messages)
Adding to what Ben said:
Incoming webhooks are limited in their functionality. They are great if you need an easy way to send a message that does not require a token, but in general the API method (chat.postMessage) is the better choice. It is more flexible (e.g. not fixed to one channel) and provides the full functionality (e.g. you get the ID for a message and can later update it).
Workspace apps / tokens where a new functionality that allowed apps to be installed in one channel only (among other things). It never left its beta stage and can be safely ignore for further development.
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.