# 关于 API 认证用户的混淆

**URL:** https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042
**Category:** Development
**Tags:** rest-api
**Created:** [2024年五月30日 23:37 UTC](https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042 "2024-05-30T23:37:43Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![BrainFried](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/brainfried/32/388499_2.png) [@BrainFried](https://meta.discourse.org/u/BrainFried)
#### Post date: [2024年五月30日 23:37 UTC](https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042/1 "2024-05-30T23:37:43Z")

</div>

我有一个关于使用 API 安全性的问题，因为我认为由于我缺乏经验，我错过了一些基本概念。

我有一个无头 Discourse 实现，用于集成到我的前端，并且我已成功启用了 SSO 进行用户身份验证。

我最初的理解是，我使用 SSO 作为“活动用户”来从 API 获取特定于活动用户的数据。我现在意识到，这并不完全正确。

我现在看到返回的数据似乎取决于标头中传递的“api-username”。但我使用的是管理员 API 密钥，我认为这意味着通过传递正确的用户名作为“api-username”，我可以获取任何我想要的用户的数据。

所以我的问题归结为，API 似乎没有引入“活动用户”的概念，我必须通过检索外部 ID 来获取用户名，然后在活动会话中始终使用该用户名作为 api-username 来调整活动用户，是这样吗？

如果我的理解是正确的，那么黑客岂不是可以轻易地修改标头中的 api-username 来检索任何用户的聊天记录？

任何额外的信息都将有助于我理解。谢谢！

一些我阅读过的相关文章：

> [@User API keys specification](https://meta.discourse.org/t/user-api-keys-specification/48536):
>
> Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators. High level description At a high level: Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url Client redirects to a route on discourse giving discourse its public key Discourse gets approval from user to use app Discourse generat…

> [@Get notifications via the API](https://meta.discourse.org/t/get-notifications-via-the-api/120951):
>
> If you have an existing website or application and you would like to encourage discussion on your Discourse forum it can be helpful to display Discourse notifications inside of your application. This guide will show you how to use the Discourse API to fetch notifications for a user and how to mark them as read. The recommended way of using the API is to have your application make back-end requests to Discourse and then pass that data to the front-end/presentation layer of your application. Che…

> [@Using Discourse API to return user data when the "Require authentication to read content on this site, disallow anonymous access." setting is checked](https://meta.discourse.org/t/using-discourse-api-to-return-user-data-when-the-require-authentication-to-read-content-on-this-site-disallow-anonymous-access-setting-is-checked/28404):
>
> Hi, I enabled the setting “Require authentication to read content on this site, disallow anonymous access”. I’m making a GET request to the /users/by-external/{EXTERNAL\_ID}.json endpoint, and without the above setting enabled, it returns a user perfectly fine. But when I enable the above setting, the GET request returns nothing. For reference, I have SSO enabled. Let me know if there’s a workaround or if I’m thinking about this incorrectly. Thanks in advance!

> [@Per User API Keys Not Working](https://meta.discourse.org/t/per-user-api-keys-not-working/201415):
>
> I’m following the guidance for getting per user api keys: [User API keys specification](https://meta.discourse.org/t/user-api-keys-specification/48536). I’ve gone through the steps: client generates a public/private key pair and return url, goes to a discourse route, user gives approval to discourse to use the app, and discourse generates an api key. But when discourse sends back the API key as a “payload” in the return url, that key doesn’t work. I try to decrypt it, but I can’t. I plug that key into some standard javascript decryption (like in the answer [h…](https://stackoverflow.com/questions/8750780/encrypting-data-with-a-public-key-in-node-js)

---

<div class="post-metadata">

### Author: ![supermathie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/supermathie/32/507518_2.png) [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [2024年五月31日 02:57 UTC](https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042/2 "2024-05-31T02:57:16Z")

</div>

> [@BrainFried](#):
>
> 一个无头版本的 Discourse，用于集成到我的前端

> [@BrainFried](#):
>
> 黑客难道不能轻易地修改标头中的 api-username 来检索任何用户的聊天记录吗？

管理员 API 密钥是通往王国的钥匙

![](https://media.tenor.com/BxBXA_6u-PQAAAAC/lotr-keep-it-safe.gif)

不要将其放在任何前端应用程序中。如果你这样做了，我建议你立即撤销它。

---

<div class="post-metadata">

### Author: ![michaeld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaeld/32/1594_2.png) [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [2024年五月31日 04:44 UTC](https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042/3 "2024-05-31T04:44:24Z")

</div>

> [@BrainFried](#):
>
> 如果我的理解是正确的，黑客难道不能轻易地修改标头中的 api-username 来检索任何用户的聊天记录吗？

你不应该从前端使用该 API，因为那样的话确实存在风险（实际上风险要高得多，因为黑客可以做任何事情）

你应该从后端执行此操作。

如果那不是一个选项，那么你应该改用用户 API 密钥。

---

<div class="post-metadata">

### Author: ![BrainFried](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/brainfried/32/388499_2.png) [@BrainFried](https://meta.discourse.org/u/BrainFried)
#### Post date: [2024年五月31日 06:13 UTC](https://meta.discourse.org/t/confusion-about-api-authenticated-user/310042/4 "2024-05-31T06:13:14Z")

</div>

作为一个无头实现，我将从我的前端运行它。所以，在这种情况下，我似乎需要花一些时间来解读关于这个话题的讨论：

> [@User API keys specification](https://meta.discourse.org/t/user-api-keys-specification/48536):
>
> Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators. High level description At a high level: Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url Client redirects to a route on discourse giving discourse its public key Discourse gets approval from user to use app Discourse generat…

与这些讨论类似，我也有兴趣使用我的管理员API访问来自动生成用户的API密钥。但是，在我的流程中，我不想让用户重定向到一个新页面来“批准”我的应用程序。我将要么想使用我可靠的管理员API密钥强制批准，或者是否有我可以禁用的设置，这样新用户API密钥就不需要额外的身份验证了？
