我正在构建我的第一个Slack机器人，我的基本知识大部分都可以正常工作……发送API请求，接收命令和事件等。但是我有些困惑的是我应该与“ Bot用户OAuth访问令牌”有关。
该令牌似乎在团队/工作区之间共享，但是在调用/oauth.v2.access的单个用户进行身份验证期间被返回。当前，我将返回的凭据有效负载存储在具有三列的表中：
authed_user.id jsonb）这使我可以为应用程序中发生的操作（通过内部用户ID查找）和Slack中的交互（通过Slack用户ID查找）发起新的API调用。
让我有些困惑的是，当用户与未添加我的应用的我的机器人进行交互时，约定是什么。当某人（“ Jose”）添加了我的应用程序，然后他们的同事（“ Mary”）在Slack中发现它并查看主屏幕，向其发送消息等时，就会发生这种情况。
为了执行某些操作，例如提示用户安装我的应用，我需要一个令牌。我当然有一个标记给何塞，但没有玛丽。我还将Jose的团队ID存储在表中，而Mary的团队ID作为传入事件的一部分存储在表中。因此，从技术上讲，我可以做这样的事情来获得与玛丽互动的有效令牌：
select credential_json from slack_credentials
where credential_json->>'type' = 'bot' and credential_json->'team'->>'id' = :marysTeamId
......将提取我在Jose添加应用程序时捕获的机器人令牌。这可行，但是感觉很不对劲。我想如果我只是将机器人令牌存储在一个像这样的单独表中：
team.id access_token，scope，bot_user_id等，但不是authed_user）然后就不会那么讨厌了。但是docs + API的人机工程学也不建议这是一种常见的方法。所以我很好奇别人在做什么。如果我什么也没听到，我想我的计划是将机器人令牌分解成一个以团队为中心的表。
谢谢！
答案 0 :(得分：1)
Slack应用程序的基本概念是，它们是按工作区而不是按用户安装的。
因此，确实可以从将您的应用程序安装到新工作区的用户那里获取应用程序的令牌，但是大多数应用程序功能对工作区的所有用户都是可用的。
例如斜杠命令将对每个通道中的每个用户有效 例如相关频道的所有用户都可以看到您应用的信息。
因此，存储令牌的最佳方法通常是使用Slack Team ID，Slack User ID作为主键。
只是为了澄清。您不需要令牌即可提示用户安装您的应用。每个应用程序都可以从您托管的网页上安装（使用“添加到松弛按钮”），也可以直接从应用程序目录中安装。