您好，我想咨询一下关于 user_api_keys 的问题。目前我正在尝试将我们的应用程序与 Discourse 的 user_api_keys 集成以进行授权。我的问题是：是否可以通过 API 检索 user_api_keys？
现在，在通过 /session.json 登录并使用 /users/:username.json 检查当前用户配置文件后，我们可以看到用户是否拥有 user_api_keys，但它不会返回实际的值：
"user_api_keys": [
{
"id": 0,
"application_name": "",
"scopes": [""],
"created_at": "",
"last_used_at": ""
}
]
我之所以想获取 user_api_keys 的值，是为了避免在用户第一次登录点击按钮授权后，还需要他们再次批准授权。
不可以，它们只显示一次，然后只存储一个哈希值。
用户 API 密钥应存储在您的应用程序中，最好是存储在最终用户的设备上。用户 API 密钥的整个目的是让用户拥有授权的“证明”，并由他们负责存储。
我不知道是否可以通过 API 检索 API 密钥的值。Discourse 不会在数据库中保存未加密的 API 密钥。即使你能检索到加密值，你的应用程序也无法解密它。
你能更详细地解释一下你的用例吗？如果一个用户已经生成了用户 API 密钥，我不明白为什么他们需要再次批准授权。
编辑：可以使用管理员 API 密钥为用户生成 API 密钥。有关详细信息，请参阅：Generate User Api Key Without User Approval - #2 by simon
重新阅读我的帖子，我发现我没有解释 $json 变量是如何为请求设置的。最简单的确定如何构造数据的方法是，通过 Discourse UI 发出请求以生成具有你想要使用的范围的单个用户 API，然后查看发送到 /admin/api/keys 的请求的请求负载值：
嘿 @RGJ，感谢您的回答。
你好 @simon，感谢你的回复。让我更详细地解释一下我们的情况。
我们正在构建一个移动应用程序，该应用程序依赖于 Discourse 端点的后端逻辑。当用户通过应用程序登录时，登录数据会通过 session.json 发送到 Discourse API，该 API 会返回一个 cookie。然后，此 cookie 用于将 webview 重定向到 /user-api-key/new，提示用户批准授权。批准后，有效负载将被解密为 API 密钥。
在这种情况下，我们可以将 API 密钥用作移动应用程序中的全局令牌来访问其他 Discourse 端点。但是，当用户注销时，令牌应从全局状态中删除，以便他们无法访问创建新主题等端点。
我的问题来自这个主题：我们如何检查用户是否已经拥有 user_api_keys 并且它们是否仍然有效？如果密钥存在且有效，用户登录后应能够使用它们。如果不是，用户将需要创建新的 user_api_keys，这需要 webview 中的批准。
这是我面临的主要问题。
我考虑的另一个解决方案是，基于 如何通过 API 检索用户 API 密钥值 的帖子，将 API 密钥存储在我们的移动应用程序数据库中。
我还参考了 无需用户批准即可生成用户 API 密钥 - #2 by simon 的帖子，我最初查看该帖子是为了实现 API 密钥。但是，问题仍然存在：当我在 /admin/api/keys 中检查时，我们无法检索数据库中已保存的 API 密钥的值，也无法获取每个用户的 API 密钥。我认为，对于此实现，我们需要将 API 密钥存储在自己的数据库中。
也许您可以生成一个与 API 密钥分开的会话令牌。使用该令牌来指示用户的登录状态。这样，您就不需要在用户注销时删除 API 密钥。
感谢您对此问题的意见。我同意将 token 存储在两个地方更好：首先，存储在全局状态中以检查用户的登录状态，其次，存储在数据库中以保存 user_api_keys。
为什么不使用 Discourse Connect？那是进行身份验证的方式。
您好，感谢您的建议。我们不在这里使用 Discourse Connect 的原因是，我们不打算将 Discourse 与任何其他网站或其他地方进行连接。所有登录功能将直接通过 Discourse 处理，应用程序也只会与 Discourse 进行交互。
您的应用是另一个地方。我敢肯定，您希望将您的应用配置为 Discourse Connect 客户端，以便人们可以通过登录 Discourse 来登录您的应用。然后，您的应用可以与 Discourse 交互，我想。或者，也许我不了解应用是如何工作的。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
