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:
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.
Alguém pode me dizer se isso é suportado atualmente ou não?
Estou com dificuldade para fazer funcionar.
Se tentar usar a API_KEY na string de consulta, recebo:
Você não tem permissão para visualizar o recurso solicitado. O nome de usuário ou a chave da API é inválido.
O que implica que está tentando ler a string de consulta, pelo menos.
Atualização:
Ok, consegui fazer isso funcionar de certa forma. Parece que um subconjunto de feeds RSS está disponível, mas não todos? Ao observar as configurações da chave da API, parece que podemos acessar:
leitura
/t/:slug/:topic_id.rssleitura de listas
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssAlguém sabe por que isso exclui o básico /latest.rss e /top.rss?
Parece que a busca do RSS com uma chave de API deve especificar um cabeçalho de aceitação para recuperar os dados corretos.
curl https://bbs.example.com/c/cat.rss?api_key=KEY, o resultado pode ser uma página < HTTP/1.1 404 Not Found.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \