Update Slack app installation flow to work with GBP
Background
Initial notes from &7729 (comment 875803434):
Update our installation flow to work with the new GBP app.
- This includes the OAuth changes mentioned in the migration guide, and also probably removing the
ChatName
creation during installation that I mentioned in #351384 (comment 875622222).- We probably also need to detect which version of the app is used, and gate these changes behind this check (and maybe also a FF).
Proposal
Update the OAuth flow in our code by following the migration guide at https://api.slack.com/authentication/migration#update_oauth.
The main changes seem to be:
- Switch to the
oauth.v2.access
endpoint at https://gitlab.com/gitlab-org/gitlab/blob/0d9b1b4a06ea8f207a2dd72336dea682b42e19de/ee/app/services/projects/slack_application_install_service.rb#L59 - Accommodate changes in the payload returned from this endpoint, compared to the previous
oauth.access
endpoint.
We'll also need:
- Some way to detect if we're dealing with a Classic or GBP app, we'll probably get some indication in the payload we receive on the
#slack_auth
endpoint at https://gitlab.com/gitlab-org/gitlab/blob/0d9b1b4a06ea8f207a2dd72336dea682b42e19de/ee/app/controllers/projects/settings/slacks_controller.rb#L16 - Skip the
ChatName
creation at https://gitlab.com/gitlab-org/gitlab/blob/0d9b1b4a06ea8f207a2dd72336dea682b42e19de/ee/app/services/projects/slack_application_install_service.rb#L28, since we now receive the user ID of a bot rather than the installing Slack user. This means that the installing GitLab user will have to authorize manually through the slash command like other users, which is probably acceptable.
This code is mainly in:
ee/app/controllers/projects/settings/slacks_controller.rb
ee/app/services/projects/slack_application_install_service.rb
Click to see original "storing bot tokens?" question
Open question: Storing bot tokens?
As @.luke pointed out in #351384 (comment 876263044) we might also receive a bot token from the oauth.v2.access
endpoint. We probably won't need this yet for the slash commands functionality, but if we can easily store this (in e.g. a new encrypted column on SlackIntegration
) we could consider doing that now already.
It doesn't seem strictly necessary though, since users will have to reauthorize once we add more scopes to the app, and we'll get another opportunity to store the bot tokens at that point.
We might be receiving a bot token to use as a Bearer token when we want to interact with the Slack workspace later on, but we can hash this out as part of &7729 (closed) and work out where to store it if we do
🙂 .
In future (I think) the bot token will be used to post back to the Slack API for
Gitlab event -> Slack
notifications (when we absorb the notifications integration into the main Slack integration), and also if we process events asynchronously.
So I think we should save the bot token somewhere from the beginning, even if we're not going to use it straight away, so we can use it in future without needing the app to be reinstalled.Edit: Hmm, the mention of progressive permissions sounds like if we later require more permission scopes likelinks.read
andlinks.write
for link unfurls, when the Slack admin updates the app, they might need to reauthorize, which might mean we don't need to save bot tokens immediately if we don't want to, so long as we add extra permission scopes later when the time comes.