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.
Don’t api keys need to be in the headers now @sam?
Yes they do! @blake any thoughts about how people will do private RSS feeds in the current world. Do browsers/rss feed things support custom headers for auth?
This is a pretty rare use case, but would be nice if we had a workaround.
The only auth related thing to rss is support for url based basic auth like https://user:password@www.example.com (which we don’t have support for) or something like what we currently support with api_key & api_username in the url.
While it would have been nice to completely retire url based auth I think the way forward so that we still have support for private rss is to only allow this type of auth for topic/category feeds, and then later we can also add support for readonly api keys.
The problem is also that rss readers usually only have a single url field for adding a feed, so even if rss had support for headers, readers don’t have a place to add credentials to a header.
One idea here related to some of @david’s scoping work is that we could make a user api key that is tightly scoped to a single RSS feed, that way the surface area is low, and in cases like that where we have an ultra scoped user api key we could allow it without headers (a column on user_api_key to say this key is can use GET for auth).
The challenges here are:
We don’t have a mechanism for users to generate user api keys, we would have to build something for the RSS use case which would involve some new UX, not sure where we would even add it, in the user profile maybe, I don’t know.
We don’t have a mechanism to scope down just to one specific RSS feed which we would have to add
We don’t have a flag for “allowed user API key” via URL GET params which would be required for this
Overall I see this as something we could solve but we are probably looking at a week or two of work here to get it working just right.
The upside is that some of this work is work we want to do regardless of RSS, but the downside is that some of the work is very tightly coupled to RSS and there are very few people who use this feature these days.
Up to @codinghorror I guess to choose how we want to prioritize this.
I’ve got WordPress and Discourse integrated with WordPress doing SSO. I’m generating a sidebar of recent posts in WordPress using RSS feeds from a number of categories using the API so would love to maintain the URL auth mechanism for that. Otherwise I’m going to have to get my hands dirty writing a custom widget to try to implement the header auth option. So I guess I’m a +1 for the few people that use it.
Can someone tell me if this is currently supported or not?
I’m struggling to make it work.
If I try using the API_KEY in query string I’m getting:
You are not permitted to view the requested resource. The API username or key is invalid.
Which implies it’s trying to read the query string at least.
Update:
OK I have this sort-of working. It seems some subset of rss feeds are available, but not all? Looking at the API key settings seems we can access:
read
/t/:slug/:topic_id.rssread lists
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssAnyone know why this excludes the basic /latest.rss and /top.rss?
It seems that the fetching the rss with api key must specify a accepting header to fetch the right data.
curl https://bbs.example.com/c/cat.rss?api_key=KEY could result to a < HTTP/1.1 404 Not Found page.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \