How to get a feed from a password protected Discourse?

[strategeek]

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?

[eviltrout (Robin Ward)]

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

[strategeek]

Great answer, eviltrout. Thank you very much

[dansingerman]

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?

[eviltrout (Robin Ward)]

@dansingerman

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?

[dansingerman]

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

[techAPJ (Arpit Jalan)]

This was a bug, now fixed via:

https://github.com/discourse/discourse/commit/f50d4478810a0d5616ba06448dcae51aaeccb192

[scombs (Steve Combs)]

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.

[codinghorror (Jeff Atwood)]

As chaves de API não precisam estar nos cabeçalhos agora, @sam?

[sam (Sam Saffron)]

Sim, eles fazem! @blake, você tem alguma ideia sobre como as pessoas vão acessar feeds RSS privados no cenário atual? Os navegadores ou leitores de RSS suportam cabeçalhos personalizados para autenticação?

Esse é um caso de uso bastante raro, mas seria ótimo se tivéssemos uma solução alternativa.

[blake (Blake Erickson)]

A única coisa relacionada à autenticação no RSS é o suporte a autenticação básica baseada em URL, como https://user:password@www.example.com (para a qual não temos suporte) ou algo como o que atualmente suportamos com api_key e api_username na URL.

Embora seria bom eliminar completamente a autenticação baseada em URL, acredito que o caminho a seguir, para que ainda tenhamos suporte a RSS privado, é permitir esse tipo de autenticação apenas para feeds de tópicos/categorias. Posteriormente, poderemos adicionar suporte a chaves de API de somente leitura.

O problema também é que os leitores de RSS geralmente possuem apenas um único campo de URL para adicionar um feed. Portanto, mesmo que o RSS tivesse suporte a cabeçalhos, os leitores não teriam onde adicionar credenciais em um cabeçalho.

[sam (Sam Saffron)]

@blake

Embora teria sido bom aposentar completamente a autenticação baseada em URL, acho que o caminho a seguir, para que ainda tenhamos suporte a RSS privado, é permitir esse tipo de autenticação apenas para feeds de tópicos/categorias. Mais tarde, podemos adicionar suporte a chaves de API somente leitura.

Uma ideia aqui, relacionada a parte do trabalho de definição de escopo do @david, é que poderíamos criar uma chave de API de usuário restrita a um único feed RSS. Dessa forma, a superfície de ataque seria reduzida e, nesses casos, onde temos uma chave de API de usuário ultra restrita, poderíamos permitir seu uso sem cabeçalhos (adicionando uma coluna em user_api_key para indicar que essa chave pode usar GET para autenticação).

Os desafios aqui são:

1. Não temos um mecanismo para os usuários gerarem chaves de API de usuário; teríamos que construir algo para o caso de uso do RSS, o que envolveria uma nova UX. Não tenho certeza de onde adicionaríamos isso, talvez no perfil do usuário, não sei.

2. Não temos um mecanismo para restringir o escopo a um único feed RSS específico, o que teríamos que implementar.

3. Não temos um indicador para “chave de API de usuário permitida” via parâmetros GET na URL, o que seria necessário para isso.

No geral, vejo isso como algo que podemos resolver, mas provavelmente estamos olhando para uma ou duas semanas de trabalho para fazer tudo funcionar corretamente.

A vantagem é que parte desse trabalho é algo que queremos fazer independentemente do RSS, mas a desvantagem é que parte do trabalho está muito acoplada ao RSS e há muito poucas pessoas que usam esse recurso atualmente.

Cabe ao @codinghorror decidir como queremos priorizar isso.

[xadium (Ali)]

@sam

O lado positivo é que parte desse trabalho é algo que queremos fazer independentemente do RSS, mas o lado negativo é que algumas tarefas estão muito atreladas ao RSS e há muito poucas pessoas que usam esse recurso atualmente.

Tenho o WordPress e o Discourse integrados, com o WordPress fazendo o SSO. Estou gerando uma barra lateral com postagens recentes no WordPress usando feeds RSS de várias categorias por meio da API, então adoraria manter o mecanismo de autenticação por URL para isso. Caso contrário, vou ter que me envolver na escrita de um widget personalizado para tentar implementar a opção de autenticação por cabeçalho. Então, acho que sou mais um a favor dos poucos que usam essa funcionalidade.

[Jack_Ukleja]

@blake

Acho que o caminho a seguir, para que continuemos com suporte a RSS privado, é permitir esse tipo de autenticação apenas para feeds de tópicos/categorias e, posteriormente, adicionar suporte a chaves de API somente leitura.

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.rss

leitura 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.rss

Alguém sabe por que isso exclui o básico /latest.rss e /top.rss?

[sptrf (Sparkcyf)]

Parece que a busca do RSS com uma chave de API deve especificar um cabeçalho de aceitação para recuperar os dados corretos.

• Se eu buscar o RSS sem especificar o cabeçalho de aceitação, como em curl https://bbs.example.com/c/cat.rss?api_key=KEY, o resultado pode ser uma página < HTTP/1.1 404 Not Found.
• No entanto, ao especificar o cabeçalho de aceitação, o XML do RSS pode ser recuperado corretamente. Por exemplo:

curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
  -H 'application/xhtml+xml' \