Slack 机器人令牌应该如何存储？

Question

我正在构建我的第一个 Slack 机器人，我的基本功能大部分都在工作...发送 API 请求、接收命令和事件等。但我有点困惑的部分是我在做什么应该与“Bot User OAuth Access Token”有关。

该令牌似乎在团队/工作区之间共享，但它在调用/oauth.v2.access 对单个用户进行身份验证期间返回。目前，我将返回的凭据有效负载存储在一个包含三列的表中：

• 我的应用的内部用户 ID
• 作为authed_user.id 嵌入在负载中的 Slack 用户 ID
• 整个 JSON 有效负载本身（如果您好奇，请使用 postgres 中的jsonb）

这使我可以为我的应用程序中发生的操作（通过内部用户 ID 查找）以及 Slack 中的交互（通过 Slack 用户 ID 查找）发起新的 API 调用。

让我有点困惑的是，当用户与我的机器人交互但没有添加我的应用时，约定是什么。当一个人（“Jose”）添加我的应用，然后他们的同事（“Mary”）在 Slack 中发现它并查看主屏幕、向它发送消息等时，就会发生这种情况。

为了采取一些行动，例如提示用户安装我的应用程序，我需要一个令牌。当然，我有一个给何塞的信物，但没有给玛丽的。我还将 Jose 的团队 ID 存储在我的表中，并将 Mary 的团队 ID 作为传入事件的一部分。所以从技术上讲，我可以做这样的事情来获得一个与 Mary 交互的工作令牌：

select credential_json from slack_credentials
where credential_json->>'type' = 'bot' and credential_json->'team'->>'id' = :marysTeamId

...这将提取我在 Jose 添加应用程序时捕获的机器人令牌。这可行，但感觉非常错误。我想如果我只是将机器人令牌存储在一个单独的表中，如下所示：

• 作为team.id 嵌入在负载中的 Slack 团队 ID
• JSON 有效负载的子集（例如：access_token、scope、bot_user_id 等，但不包括 authed_user）

这样就不会觉得那么恶心了。但是 docs + API 人体工程学也不表明这是一种常见的方法。所以我很好奇别人是怎么做的。如果我没有收到任何回复，我想我的计划是将机器人令牌分解为以团队为中心的表格。

谢谢！

Answer 1

Slack 应用程序的基本概念是它们是按工作区而不是按用户安装的。

因此，虽然应用的令牌确实来自将应用安装到新工作区的用户，但大多数应用功能对工作区的所有用户都可用。

例如斜杠命令适用于每个频道中的每个用户 例如相关频道的所有用户都可以看到您应用的帖子。

因此，存储令牌的最佳方法通常是使用 Slack Team ID 的主键，即 Slack User ID。

只是为了澄清。您不需要令牌来提示用户安装您的应用程序。每个应用程序都可以从您托管的网页安装（使用“添加到 Slack 按钮”）或直接从应用程序目录安装。