slackapi / bolt-python

A framework to build Slack apps using Python

Home Page:https://slack.dev/bolt-python/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support multiple workspaces for bot and slack login

kennym opened this issue · comments

  1. We have a Slack app that needs to handle events from multiple Slack workspaces.
  2. We also need to support Slack Login via the same app.

We have been using Socket Mode so far which works great for a single workspace, but now that we need to support multiple Slack workspaces that approach seems to fall short.

We've moved away from Socket Mode and I set up a publicly accessible Request URL and I see the requests being handled in our Django app.

However, our bot is not able to respond anymore. When I message our bot, I see the following error message:

multi_teams_authorization slack_bolt.MultiTeamsAuthorization.process:93: Although the app should be installed into this workspace, the AuthorizeResult (returned value from authorize) for it was not found.

Our setup is basically identical to the one from the Django OAuth example and I wonder why this is happening.

We have one slack_bolt.App configuration for both the Bot installation and the Slack Login.

Questions:

  1. Why are we getting that error message when a user sends a message to the bot?
  2. (Answered below) Is it recommended to use Socket Mode or event subscriptions via the Request URL (webhook) if we plan on supporting multiple workspaces, or does it not matter?
  3. Should we be using two different slack_bolt.App instances for the Bot Installation and Slack Login respectively as laid out here?

Reproducible in:

django-slack==5.19.0
slack-bolt==1.18.1
slack-sdk==3.26.1
Python 3.11.6
ProductName:            macOS
ProductVersion:         14.1.2
BuildVersion:           23B92

The slack_bolt version

django-slack==5.19.0
slack-bolt==1.18.1
slack-sdk==3.26.1

Python runtime version

Python 3.11.6

OS info

ProductName: macOS
ProductVersion: 14.1.2
BuildVersion: 23B92
Darwin Kernel Version 23.1.0: Mon Oct 9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000

Is it recommended to use Socket Mode or event subscriptions via the Request URL (webhook) if we plan on supporting multiple workspaces, or does it not matter

@seratch gave a pretty answer to this already here: #982 (comment)

Hi @kennym, thanks for asking the questions.

Why are we getting that error message when a user sends a message to the bot?

The only reason why this could happen is that you might installed the app via the Install the App button on the admin page, not the OAuth flow that your app serves, which starts from https://{your public domain}/slack/install URL. When you enable OAuth flow along with token management using InstallationStore, all installations must be managed by the InstallationStore. The installations that are done from the admin page won't be managed in the datastore. This is why the middleware fails to find a relevant installation and its tokens for the request. To resolve it, you need to install the app again through the OAuth flow starting at /slack/install.

Should we be using two different slack_bolt.App instances for the Bot Installation and Slack Login respectively as laid out #574 (comment)?

If you mean Sign in with Slack by "Slack Login", yes yous should. Your OAuth flow must be separately defined. Still, you may be able to reuse some of the App settings such as client_id etc., however, the endpoint for Sign in with Slack must be a different one. It seems that you're running an app built with Django. You can add URLs for Sign in with Slack in the routing file "urls.py".

I hope this helps.

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.