双 Discourse API 系统的用途

我希望澄清 Discourse 的两个 API 认证系统分别在何时以及出于何种目的运行。

(来自 此处)。以下是我目前的最佳理解:


管理 API(有时也称为 JSON API)适用于以下情况:您希望调用 API 与 Discourse 论坛进行交互,并且满足以下条件之一:

  1. 这些调用不需要任何认证,或
  2. 这些调用需要认证,但您也直接控制该 Discourse 论坛,因此您可以手动生成 API 密钥,供您的论坛和/或独立应用程序使用以进行 API 调用。

另一方面,用户 API 适用于以下情况:您希望与 Discourse 论坛(或多个论坛)进行交互,这些交互需要认证,并且您控制您希望与之交互的论坛(或多个论坛)。

换一种说法:管理 API 适用于您控制论坛的情况,而用户 API 适用于您不控制论坛的情况。

我的理解正确吗?

例如,@david此处 的描述指出,管理 API 不应用于 JavaScript 客户端。但我认为,只要使用 JavaScript 客户端的应用程序所有者也控制该论坛(即独立应用程序的所有者与论坛的所有者是同一人),就可以使用管理 API 配合 JavaScript 客户端。对吗?

我认为情况确实如此。如果您希望从独立应用程序向 Discourse 站点调用管理 API,那么您应该在后端(服务器端)进行这些调用。如果您不从后端调用,而是从客户端调用,可能会遇到 CORS 限制。在这种情况下,您可以在 admin/site_settings/security/ → “cors origins”(跨域来源)中将独立应用程序的域名加入白名单。

下面我还包含了关于这些 API 如何工作的更多细节。我还有一个问题:在为管理 API 设置 API 密钥时,在什么情况下使用“所有用户”作为用户级别是合适的?

更多细节:

管理 API

基础

这是 docs.discourse.org 上描述的 API,有时也称为 JSON API。

通过与此 API 的端点交互,您可以执行几乎任何可以在 Discourse 站点上直接执行的操作,方法参见 此处

某些端点需要认证。例如,如果您想使用 API 检索特定组的详细信息(端点:[your-forum]/groups/[group-name].json),但该组仅对其成员可见,那么您需要“代表”其中一个成员调用该端点。

要使用正确的认证进行 API 调用,您需要在 [your-forum]/admin/api → 新建 API 密钥处生成一个 API 密钥,为该密钥选择用户级别“单个用户”,并选择一个有权查看该资源的用户(例如有关组的信息)。

然后在进行 API 调用时,您需要包含以下标头:将密钥作为 Api-Key,将用户名作为 Api-Username

在设置 API 密钥时,还有一个选项是选择“所有用户”。正如我上面提出的问题,我不确定在什么情况下使用“所有用户”是合适的,而不是选择单个用户并将其设为管理员。

何时使用

您可以从 Discourse 应用“内部”使用管理 API。因此,您可以从以下位置与管理 API 进行交互:(i) 每个主题下的编辑 CSS/HTML 仪表板(位于 [your-forum]/admin/customize),(ii) 集成到您的 Discourse 站点中的主题,以及 (iii) 集成到您的 Discourse 站点中的插件。

如果您控制 Discourse 论坛,从而可以通过论坛手动生成独立应用程序将使用的 API 密钥,您也可以从独立应用程序使用管理 API。

正如我上面提出的问题,我希望确认这一理解。

用户 API

此 API 的详细信息描述在:User API keys specification

我认为用户 API 的存在是因为管理 API 并不打算作为可供任何与您的论坛分离的站点或应用程序访问的通用 API。

为了明确这一点:独立应用程序可能与您的 Discourse 论坛交互的情况有两种:

场景 1:无直接连接:一位与 Discourse 论坛无关联的开发者创建了一个与该论坛交互的应用程序。例如,一位不是论坛管理员或与论坛管理员无关联的开发者希望创建一个应用程序,用于轮询各种 Discourse 站点以获取某些事实或信息。

在这种情况下,Discourse 论坛管理员不会手动生成 API 密钥提供给无关联的开发者。因此,管理 API 并不适用。

因此,就像许多网站(如 YouTube)拥有 API 供第三方开发者在其开发的应用程序中使用以与 YouTube 交互一样,Discourse 用户 API 是一种让第三方应用程序通过让使用这些应用程序的客户端(桌面、手机)生成 API 密钥从而获得对论坛有限访问权限的方式。

场景 2:直接连接的应用程序:论坛管理员(或与管理员有关联的开发者)连接到一个独立的应用程序,该应用程序希望与论坛进行交互。

例如,管理员可能希望有一个具有非 Discourse 功能的独立应用程序,并希望该独立应用程序的用户与论坛的用户有所重叠。在这种情况下,管理员实际上可以直接(通过论坛管理员仪表板手动)生成 API 密钥并提供给独立应用程序使用,从而使独立应用程序能够利用管理 API。

如果您将 API 密钥打包在应用程序中,黑客很容易从应用程序二进制文件或网络协议中提取该密钥。

用户 API 则不受此问题影响:用户授权应用程序后,系统会为其生成专用的 API 密钥。

那么,管理 API 的主要使用场景是什么?

在我的情况下,我使用它来:

  1. 通过 API 调用将数据添加到论坛并展示。另一种方法是通过插件嵌入 Ember/Rails 代码来创建不同类型的数据并展示。我目前选择使用 API,是因为从编程角度看,理解 API 并使用 JavaScript 与之交互,远比掌握 Discourse 代码库、精通 Ember 和 Rails 要容易得多。
  2. 允许我开发的独立应用与我的论坛进行交互。

在这两种情况下,用户 API 都无法适用,因为需要检索并展示的数据通常并非特定于某个用户。我理解您的观点,即不应将 API 密钥暴露在前端。为解决这一问题同时仍使用管理 API,我将密钥托管在后台服务中,论坛通过调用该后台服务来间接访问。因此,论坛仅暴露后台服务的端点 URL(这无关紧要),而不会暴露托管在该处的 API 密钥。

用户 API 正是为此设计的,请参阅 Discourse Hub 的源代码以获取参考实现。

管理 API 的设计用途是什么?

管理 API 用于服务器到服务器的交互,例如从网站后端发起的调用。