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.
¿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' \