Slack app support #4211
Open
Slack app support #4211
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pharaujo
force-pushed
the
slack_token_auth
branch
2 times, most recently
from
c9c52d3 to
c32a184
Compare
While it's possible to configure Slack app bot tokens using a combination of http_configs authorization credentials and setting the Slack API URL to the a specific endpoint, doing so at a global level leaks the token to any other notification receiver configured, as http_configs are not specific to notifiers. Slack has also restricted webhook URLs to only be able to post to a single channel (with the legacy webhooks being [marked as deprecated and not recommended][1]), which reduces their usefulness when set at the global level. This PR adds a way of easily setting Slack App bot tokens at the global level, as well as overriding at the individual receiver level, while keeping compatibility with existing configurations. The decision to have a separate config field for the URL was to be able to provide a default API URL for Slack apps as well as differentiate when a webhook url is provided. Ideally we'd change the `slack_api_url` to be `slack_webhook_url` so as to avoid confusion, but that would be an unnecessary breaking change. More context in issue prometheus#2513 [1]: https://api.slack.com/legacy/custom-integrations/messaging/webhooks Signed-off-by: Pedro Araujo <[email protected]>
pharaujo
force-pushed
the
slack_token_auth
branch
from
c32a184 to
d6d3160
Compare
|
So we do also need BlockKit support, and I think this feature, along with BlockKit, would be perfect for a Slack V2 integration, just like we did for Microsoft Teams. |
I'm a bit confused. Is this feedback for me, or for other reviewers? Are you saying I should implement this under a new slack integration, or close this PR since someone else is implementing it together with Block Kit? To be clear, I'm able to change the PR to kickstart the new slack integration and plug internals into the current integration, but I don't want to extend the scope of this PR to add such a large piece of work such as Block Kit. What's the recommendation here? |
The [Slack app support issue][1] suggested setting the slack API URL to the `chat.PostMessage` endpoint instead of a webhook URL, and so people migrating from this workaround to the the new configuration might encounter a situation where they want to set the `slack_app_token` at the global level while still retaining the `slack_api_url` while dynamically configured receivers (such as those set by prometheus operator) are migrated. Signed-off-by: Pedro Araujo <[email protected]> [1]: prometheus#2513
Signed-off-by: Pedro Araujo <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While it's possible to configure Slack app bot tokens using a combination of http_configs authorization credentials and setting the Slack API URL to the a specific endpoint, doing so at a global level leaks the token to any other notification receiver configured, as http_configs are not specific to notifiers. Slack has also restricted webhook URLs to only be able to post to a single channel (with the legacy webhooks being marked as deprecated and not recommended), which reduces their usefulness when set at the global level.
This PR adds a way of easily setting Slack App bot tokens at the global level, as well as overriding at the individual receiver level, while keeping compatibility with existing configurations.
The decision to have a separate config field for the URL was to be able to provide a default API URL for Slack apps as well as differentiate when a webhook url is provided. Ideally we'd change the
slack_api_urlto beslack_webhook_urlso as to avoid confusion, but that would be an unnecessary breaking change.More context in issue #2513