The discussion revolves around accessing a password-protected Discourse feed on an external WordPress site using Single Sign-On (SSO). strategeek initially asked for help, and eviltrout suggested generating an API key for a user account and appending it to the URL. However, this approach raises security concerns, as the API key can be used to perform actions as the underlying user account.
eviltrout also warned against generating an “All Users” API key, which could compromise the entire site. dansingerman reported an issue where RSS feeds with read restrictions do not work with API keys, even when the key is valid for the user. This was confirmed to be a bug by eviltrout and later fixed by techAPJ.
However, scombs reported that the fix only resolves the issue for restricted categories, not the “Latest” feed. codinghorror noted that API keys now need to be passed in headers, not URLs. sam and blake discussed the challenges of implementing private RSS feeds with API keys, as most RSS readers do not support custom headers.
sam proposed a solution involving tightly scoped user API keys, but this would require significant development work. xadium expressed interest in maintaining the URL auth mechanism for private RSS feeds, citing a use case where they integrate WordPress and Discourse. Jack_Ukleja reported mixed results when using API keys for private RSS feeds, with some feeds working but others not. sptrf suggested that specifying an accepting header is necessary to fetch the correct RSS data with an API key.
Hello. I need to display password protected Discourse feed on the external site. How to do that?
Other sites suggest using this structure http://[username]:[password]@[domain]/[path]
But for Discourse it doesn’t work.
By the way, the external site that I want to show the feed is a wordpress page. Discourse is linked to this page with SSO.
Any ideas?
I assume you mean RSS feeds.
You can generate an API key for a user account on your site in the admin section. Then you can just append it to any URL like so:
http://meta.discourse.org/latest.rss?api_key=KEYHERE
I should note there are security issues with making that api key visible to users. If someone has it, they can do anything that the underlying user account can do. It would be much better to fetch the RSS server side using the key then only exposing the resulting feed.
Also, be especially careful not to generate an “All Users” key for this. If someone gets that key they can do anything as any user on your site. So just be extra careful 
Great answer, eviltrout. Thank you very much
We are having the issue that the RSS feeds do not work with an api_key if the categories have read restrictions, even if the api_key is valid for a user that should be able to access the category.
Is this a bug or by design?
That sounds like a bug to me. The API key should function as the user associated with it. Are you passing the correct username through too?
No, I’m not passing a username, as I am using a key associated with a user.
If I try in an unauthenticated session:
http://myserver.example.com/latest.json?api_key=my_api_key
I get the results I expect
If I try
http://myserver.example.com/latest.rss?api_key=my_api_key
I get no results.
So unless RSS has some special case of how to use API keys, I think it may be a bug
This was a bug, now fixed via:
https://github.com/discourse/discourse/commit/f50d4478810a0d5616ba06448dcae51aaeccb192
With the new fix, I am able to view restricted categories in the RSS feed at …
http://myserver.example.com/c/my_category.rss?api_key=my_api_key
but Latest only shows public topics in the RSS feed
http://myserver.example.com/latest.rss?api_key=my_api_key
Is this still unresolved or am I missing something? Thanks.
现在 API 密钥不需要放在请求头里了吗 @sam？
是的，确实如此！@blake 对于在当前环境下如何实现私有 RSS 订阅，你有什么想法吗？浏览器或 RSS 阅读器是否支持通过自定义头部进行身份验证？
这是一个比较罕见的用例，但如果能有变通方案就太好了。
与 RSS 相关的唯一身份验证功能是支持基于 URL 的基本身份验证，例如 https://user:password@www.example.com（我们目前尚不支持此功能），或者支持我们当前通过 URL 中的 api_key 和 api_username 实现的方式。
虽然完全弃用基于 URL 的身份验证会很理想，但为了继续支持私有 RSS，我们目前的推进方向是仅允许此类身份验证用于主题/分类源，之后我们还可以添加对只读 API 密钥的支持。
问题还在于，RSS 阅读器通常只有一个用于添加源的 URL 字段，因此即使 RSS 支持请求头，阅读器也没有地方将凭据添加到请求头中。
这里有一个与@david 的部分范围界定工作相关的想法：我们可以创建一个严格限定于单个 RSS 订阅源的用户 API 密钥。这样一来，暴露面就会很小。在这种情况下，对于这种超范围限定的用户 API 密钥，我们可以允许其在不使用请求头的情况下进行认证（即在 user_api_key 表中增加一列，标记该密钥可用于通过 GET 请求进行认证）。
目前的挑战在于：
我们还没有让用户生成用户 API 密钥的机制。我们需要为 RSS 用例构建一些功能，这将涉及新的用户体验设计。我不确定应该将其添加在哪里，也许是在用户个人资料中，目前还不确定。
我们还没有将权限范围缩小到单个特定 RSS 订阅源的机制，这需要添加。
我们还没有用于“允许用户 API 密钥”的 URL GET 参数标志，而这是实现此功能所必需的。
总体而言，我认为这是我们可以解决的问题，但可能需要一到两周的时间才能将其完善。
有利的一面是，其中一些工作是我们无论如何都想做的，与 RSS 无关；但不利的一面是，部分工作与 RSS 紧密耦合，而如今使用此功能的人非常少。
具体如何优先处理，我想由@codinghorror 来决定。
我已将 WordPress 与 Discourse 集成，并让 WordPress 通过 SSO 进行单点登录。我目前正利用 API 从多个分类的 RSS 源生成 WordPress 侧边栏中的最新文章列表，因此非常希望保留该 URL 认证机制。否则，我就不得不亲自动手编写自定义小部件，尝试实现头部认证选项。所以我想，我是那少数使用此功能的人之一，支持这一需求。
有人能告诉我目前是否支持此功能吗？
我努力尝试使其生效，但遇到了困难。
如果我尝试在查询字符串中使用 API_KEY，会收到以下错误：
您无权查看请求的资源。API 用户名或密钥无效。
这表明系统至少在尝试读取查询字符串。
更新：
好的，我现在让这功能部分生效了。似乎只有部分 RSS 源可用，并非全部？查看 API 密钥设置，我们发现可以访问：
读取
/t/:slug/:topic_id.rss读取列表
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rss有人知道为什么这排除了基本的 /latest.rss 和 /top.rss 吗？
看来使用 API 密钥获取 RSS 时，必须指定 Accept 请求头才能获取到正确的数据。
curl https://bbs.example.com/c/cat.rss?api_key=KEY，可能会导致返回 \u003c HTTP/1.1 404 Not Found 页面。curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \