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.
Les clés d’API ne doivent-elles pas être dans les en-têtes maintenant @sam ?
Oui, ils le font ! @blake, as-tu des idées sur la façon dont les gens pourront gérer des flux RSS privés dans le monde actuel ? Les navigateurs et les agrégateurs de flux RSS prennent-ils en charge les en-têtes personnalisés pour l’authentification ?
C’est un cas d’usage assez rare, mais ce serait sympa de trouver une solution de contournement.
La seule fonctionnalité liée à l’authentification pour RSS est la prise en charge de l’authentification HTTP basique via l’URL, comme https://user:password@www.example.com (ce que nous ne prenons pas en charge) ou quelque chose de similaire à ce que nous prenons actuellement en charge avec api_key et api_username dans l’URL.
Bien qu’il aurait été préférable de mettre définitivement fin à l’authentification via l’URL, la voie à suivre pour continuer à prendre en charge les flux RSS privés consiste à autoriser ce type d’authentification uniquement pour les flux de sujets/catégories. Par la suite, nous pourrons également ajouter la prise en charge des clés API en lecture seule.
Le problème est également que les lecteurs RSS ne disposent généralement que d’un seul champ URL pour ajouter un flux. Ainsi, même si RSS prenait en charge les en-têtes, les lecteurs n’ont aucun endroit pour ajouter des identifiants dans un en-tête.
Une idée liée à certains travaux de définition de périmètre de @david serait de créer une clé API utilisateur strictement limitée à un seul flux RSS. De cette façon, la surface d’attaque serait réduite. Dans des cas comme celui-ci, où nous disposons d’une clé API utilisateur ultra-restreinte, nous pourrions l’autoriser sans en-têtes (en ajoutant une colonne sur user_api_key pour indiquer que cette clé peut être utilisée pour l’authentification via GET).
Les défis à relever sont les suivants :
Nous n’avons pas de mécanisme permettant aux utilisateurs de générer des clés API utilisateur. Nous devrions donc en créer un pour le cas d’usage RSS, ce qui impliquerait de concevoir une nouvelle interface utilisateur. Je ne suis pas sûr de savoir où l’ajouter, peut-être dans le profil utilisateur, mais je ne sais pas.
Nous n’avons pas de mécanisme pour restreindre l’accès à un seul flux RSS spécifique, ce que nous devrions ajouter.
Nous n’avons pas de drapeau pour autoriser une « clé API utilisateur » via les paramètres GET de l’URL, ce qui serait nécessaire pour cela.
Dans l’ensemble, je considère cela comme quelque chose que nous pouvons résoudre, mais il faudra probablement une semaine ou deux de travail pour que cela fonctionne parfaitement.
L’avantage est que certaines de ces tâches sont des travaux que nous souhaitons réaliser indépendamment de RSS, mais l’inconvénient est que certaines sont très étroitement liées à RSS et que très peu de personnes utilisent cette fonctionnalité de nos jours.
À @codinghorror de décider comment nous souhaitons prioriser cela.
J’ai intégré WordPress et Discourse, avec WordPress gérant l’authentification unique (SSO). Je génère une barre latérale avec les publications récentes dans WordPress en utilisant les flux RSS de plusieurs catégories via l’API, et j’aimerais donc conserver le mécanisme d’authentification par URL pour cela. Sinon, je vais devoir me salir les mains en écrivant un widget personnalisé pour essayer d’implémenter l’option d’authentification par en-tête. Donc, je suppose que je fais partie des quelques personnes qui utilisent cette fonctionnalité et que je suis d’accord (+1).
Quelqu’un peut-il me dire si cela est actuellement pris en charge ou non ?
J’ai du mal à faire en sorte que cela fonctionne.
Si j’essaie d’utiliser la clé API dans la chaîne de requête, je reçois :
Vous n’avez pas l’autorisation d’afficher la ressource demandée. Le nom d’utilisateur ou la clé API est invalide.
Ce qui implique qu’il essaie au moins de lire la chaîne de requête.
Mise à jour :
OK, cela fonctionne en quelque sorte. Il semble qu’un sous-ensemble de flux RSS soit disponible, mais pas tous ? En examinant les paramètres de la clé API, il semble que nous puissions accéder à :
lecture
/t/:slug/:topic_id.rsslecture des listes
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssQuelqu’un sait pourquoi cela exclut les flux de base /latest.rss et /top.rss ?
Il semble que la récupération du flux RSS avec une clé API nécessite de spécifier un en-tête d’acceptation pour obtenir les bonnes données.
curl https://bbs.example.com/c/cat.rss?api_key=KEY, cela peut entraîner une page < HTTP/1.1 404 Not Found.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \