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.
¿No es necesario que las claves de API estén ahora en los encabezados, @sam?
¡Sí, lo hacen! @blake, ¿tienes alguna idea sobre cómo las personas podrían usar feeds RSS privados en el mundo actual? ¿Los navegadores o lectores de feeds RSS admiten encabezados personalizados para la autenticación?
Este es un caso de uso bastante raro, pero sería genial si tuviéramos una solución alternativa.
Lo único relacionado con la autenticación en RSS es el soporte para autenticación básica basada en URL, como https://usuario:contraseña@www.ejemplo.com (lo cual no tenemos implementado) o algo similar a lo que actualmente soportamos con api_key y api_username en la URL.
Aunque habría sido ideal eliminar por completo la autenticación basada en URL, creo que el camino a seguir, para seguir dando soporte a feeds RSS privados, es permitir este tipo de autenticación solo para feeds de temas o categorías, y más adelante también podríamos agregar soporte para claves de API de solo lectura.
El problema también es que los lectores de RSS suelen tener un solo campo de URL para agregar un feed, por lo que incluso si RSS tuviera soporte para encabezados, los lectores no tendrían un lugar para agregar credenciales a un encabezado.
Una idea relacionada con parte del trabajo de alcance de @david es que podríamos crear una clave de API de usuario que esté estrictamente acotada a un solo feed RSS. De esta manera, la superficie de ataque es baja, y en casos como ese, donde tenemos una clave de API de usuario ultra acotada, podríamos permitir su uso sin encabezados (una columna en user_api_key para indicar que esta clave puede usar GET para autenticación).
Los desafíos aquí son:
No tenemos un mecanismo para que los usuarios generen claves de API de usuario; tendríamos que construir algo para el caso de uso de RSS, lo que implicaría una nueva experiencia de usuario (UX). No estoy seguro de dónde la agregaríamos, quizás en el perfil del usuario, no lo sé.
No tenemos un mecanismo para acotar el acceso a un solo feed RSS específico, lo cual tendríamos que agregar.
No tenemos un indicador para “clave de API de usuario permitida” mediante parámetros GET en la URL, lo cual sería necesario para esto.
En general, veo esto como algo que podríamos resolver, pero probablemente estemos hablando de una o dos semanas de trabajo para que funcione perfectamente.
La ventaja es que parte de este trabajo es algo que queremos hacer independientemente de RSS, pero la desventaja es que parte del trabajo está muy estrechamente acoplado a RSS y hay muy pocas personas que utilizan esta función en la actualidad.
Depende de @codinghorror, supongo, decidir cómo queremos priorizar esto.
Tengo WordPress y Discourse integrados, con WordPress gestionando el SSO. Estoy generando una barra lateral con las publicaciones recientes en WordPress mediante feeds RSS de varias categorías usando la API, por lo que me encantaría mantener el mecanismo de autenticación por URL para ello. De lo contrario, tendré que ensuciarme las manos escribiendo un widget personalizado para intentar implementar la opción de autenticación mediante encabezados. Supongo que soy un +1 por las pocas personas que lo utilizan.
¿Alguien puede decirme si esto es compatible actualmente o no?
Me está costando hacerlo funcionar.
Si intento usar la API_KEY en la cadena de consulta, obtengo:
No tienes permiso para ver el recurso solicitado. El nombre de usuario o la clave de la API no son válidos.
Lo que implica que al menos está intentando leer la cadena de consulta.
Actualización:
Vale, esto funciona de alguna manera. Parece que hay un subconjunto de feeds RSS disponibles, pero no todos. Al revisar la configuración de la clave de API, parece que podemos acceder a:
Leer
/t/:slug/:topic_id.rssLeer 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¿Alguien sabe por qué esto excluye los básicos /latest.rss y /top.rss?
Parece que al obtener el RSS con una clave de API, es necesario especificar un encabezado de aceptación para recuperar los datos correctos.
curl https://bbs.example.com/c/cat.rss?api_key=KEY, podría resultar en una página < HTTP/1.1 404 Not Found.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \