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.
Related
I'm completely new to slack development and I might sound crazy here.
This is what I have noticed. Whenever I use my incoming webhook URL to test messages using postman, it works fine. BUT, when I use it in my app and push the code in github (so it deploys to heroku), the incoming webhook gets removed. Is this something expected and that I missed reading in the documentation?
Ok, got answer to this. Basically, got an email from slack explaining the reason.
We recently discovered a publicly accessible incoming webhook associated with the Journey Alert Bot app installed on your sync.slack.com workspace. This can happen when someone who created or has access to a webhook URL posts it on a public site, such as Github or other code-sharing forums. None of your data is at risk — webhooks can only send messages into Slack and cannot access any data.
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.
:(
What we are trying to do
I am working on automation which posts messages to a Slack channel using Incoming Webhooks on a custom Slack App. The messages mentions people.
What works
We can send a message just fine, it has formatted content, and usernames are correctly resolved using the link-names flag.
What isn't working
The whole point of the notification is to inform a dynamic set of people about something they should care about. The set of people we tag varies hugely (think people who contributed to a pull request) and so not all possible recipients are in the channel these automated messages go to.
We assumed that given the usernames are being directly #-mentioned, they would be notified by Slack. However, two of the users we've tested with and #-mentioned confirm they never received a notification they had been tagged.
This is different to "human" behaviour, where if you #-mention someone in Slack, you get a little message reminding you that person isn't in this channel and offers to invite them or let them know.
As far as we can tell, sending the message programmatically is doing the equivalent of "Do nothing" in the picture above. I want to do either of the other two options, preferably "Let them know".
How can I notify people they've been mentioned? I've looked at all the API documentation and nothing discusses notifying users who aren't in the channel that they are mentioned.
This can't be an uncommon issue.... right?
Notes:
We aren't directly calling chat.postMessage, it's just the only documentation on link_names I could find to link to. We are using Incoming Webhooks, which has minimal documentation on the parameters - it seems to be the same as chat.postMessage.
We would prefer not to move off Incoming Webhooks, but we can do a custom integration with the API if we have to.
You need to invite the user to the channel first, using the Python client that's:
client.channels_invite(
channel=channel_id,
user=user_id
)
I created a Slack app that sends a series of interactive messages to a channel. In my Slack API dashboard, I see that I can create and remove hooks. Right now the hook url that I have set up in my code is the one for the Slackbot channel.
But the problem is that such a message only gets sent to me.
I want to send the Slackbot messages to Alice in situation A, and to Bob in situation B. Not just to myself, the guy who configured the app.
What's the best way to do this?
I would suggest that you should not use hooks for this. A more sane way to do this right would be via chat.postMessage Web API method which is documented here!
This is because hooks are tied to specific conversations and that approach quickly hits a wall on what it can really achieve, especially messaging different people. Once you start using the web API it's pretty simple. Just ask for the scope during app installation (remember to add that scope in your dashboard), subscribe to the event in your API dashboard and then you are good to go.
Everytime you send a message via that method, Slack will send you a payload which you can use for testing and logging etc.
You can see all the different ways to message programmatically inside Slack here.
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.