We have created a Custom Integrations Incoming WebHooks configuration so that we can post notification from our CI pipeline into our slack channel. This works great so far, but today a colleague accidentally broke it by changing the target channel. Fortunately, there was a notification about this in our channel ("removed an integration from this channel: incoming-webhook"), so we were able to revert this quickly. But things would have been worse if the colleague only had regenerated the webhook URL... Naturally, we'd like to avoid this.
So, I am wondering if it is possible to restrict write access to our Incoming WebHooks configuration?
There seems to be a restriction if the target channel is private ‒ but I'd prefer that we can leave our channel public.
Incoming Webhooks count as Apps and the permission to modify them can be restricted to members with certain roles in the Slack workspace settings.
Most Slack admins will restrict access to managing apps to owners only and give that critical role to a few trusted members only.
If your incoming webhooks are Internal integrations and not Slack apps, then restricting them can be a problem. A solution would be to embed the incoming webhooks in a regular Slack app, which can be restricted.
Today I got a response from Slack support, and they say that they don't have a fine-grained permission model for controlling access to specific configurations. The only options are "everyone can change the configuration" or "only one person can edit the configuration".
The "only one" option is enabled by changing the "Post to Channel" property to a private channel (or direct message). Note that this doesn't mean that the configuration is restricted to the specified channel. Custom Integrations Incoming WebHooks allow the sender to override the channel, so the configuration may still be used to post to public channels.
Related
My organization recently implemented Microsoft Teams and is experiencing issues with users tagging #General unnecessarily, posting in the wrong channel, and posting inappropriate content (not necessarily NSFW but off-topic).
Slack has third-party tools that allow you to set rules for a channel and, if a rule is triggered, the message is automatically deleted. For example, if a user inadvertently tapped their yubikey and sent it to the entire organization, there is a bot that will recognize the key and immediately delete the message. It's effectively the same concept as the AutoMod functionality in Reddit.
I've been looking all over the place but can't seem to find any articles about this type of feature. Does Microsoft Teams allow for any functionality like this?
Currently Teams have functionalities such as sending notification from external app to Teams channel via incoming webhook. And also using proactive message notifications.
https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook
https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages?tabs=dotnet#get-the-user-id-or-teamchannel-id
I have a Slack bot that is working fine and interacting with users. I'm using Bot Framework composer and the Slack Adapter.
In the Slack API portal I'm trying to change the Events Request Url the app uses to send Slack Events to my bot.
When I do that, slack sends a challenge request to my bot. The bot first tries to verify that the request is really coming from Slack following: https://api.slack.com/authentication/verifying-requests-from-slack#a_recipe_for_security
The problem is that this is failing and I can't understand why.
I see that Slack is sending all the right content, and that the ClientSigningSecret is being read, otherwise the other calls to the bot wouldn't work.
I know it's a bit far fetched to ask this since it seems to be a problem on my side. But since the bot is validating the requests just fine when users talk to the bot, and the code is from the Slack Adapter which is open source and there's nothing else I can thing of..... maybe someone struggled with the same problem.
I created a support ticket to Slack and they came back pretty quickly.
Pre publish state
Before publishing a Slack app the only configs that exist are the ones you see in the App configuration page. Those are what you use to test your app, this includes the secrets to authenticate the incoming messages from Slack into your backend.
After you publish your Slack App for the first time
Once your app is published, the production version that your users use will see the original settings, including the secrets and these are the ones your backend will get.
The settings you see in the configuration page are like development mode and they won't be persisted into the published app until you request Slack to approve your changes. That's sounds great and is what one would expect, but what you don't see and have no way of imagining is happening is that there are some development time secrets that are different from the ones you see on the settings screen.
When you change the endpoint url to be sent to your backend so that it can return the challenge and Slack would accept the new url, the message payload goes with this development secret and not the one you configured your backend with. Thus your backend will reject the call since it thinks it's not coming from Slack.
Proposed solution from Slack
Don't validate the signature of the incoming request for this type of call in an already published app. I don't like it but there was no other workaround unless Slack changes this. So what I did was:
Remove that check only for this request from the backend and publish to production.
Make the url change in Slack.
Revert the change from the backend.
:(
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.
We have created an Incoming WebHooks configuration so that Dynatrace can post alerts to our development channel. This worked great for a while, but later on, we decided to use a separate "operations" channel for notifications. So I changed the "Post to Channel" setting of our Incoming WebHooks configuration and expected that the notifications would appear in the new channel.
However Slack seems to ignore my new "Post to Channel" setting. It keeps posting to the previously configured channel. What am I doing wrong?
I also noticed that the other attributes in the configuration seem to be ignored. E.g. we did not customize the name and icon, but the alerts were still posted with the name "Dynatrace" and a Dynatrace icon. But I am sure that I'm looking at the right configuration because I navigated to the configuration from one of the alert posts. This is really confusing...
This problem was driving me nuts, so I decided to post it here - including the solution that I had found in the meantime:
If the Incoming WebHooks app has certain permissions, the caller of the web hook URL may override the configured channel, name, and icon. This is why messages posted via a specific Incoming WebHooks configuration may be using completely different settings!
Dynatrace is using these override features for alert messages, so alerts will always go to the channel configured on Dynatrace side.
I want to have channel where users can ONLY send messages in threads. Is it possible? I tried with Stacktodo, but I did not found a way to do it.
Yes, Slack allows to restrict write access to channels, but only for the #general channel. There you can restrict access to admins only or even owners only.
If you want to restrict write access to other channels or use a more granular access list you need to use a Slack app like Stacktodo (with their so called Block Bot) or build your own Slack bot that provides that additional functionality.
Please contact the support team from Stacktodo if you can not get it to work.