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.
Müssen API-Keys jetzt nicht in den Headern sein, @sam?
Ja, das tun sie! @blake, hast du Gedanken dazu, wie Leute private RSS-Feeds in der heutigen Welt nutzen können. Unterstützen Browser oder RSS-Feed-Dienste benutzerdefinierte Header für die Authentifizierung?
Das ist ein ziemlich seltenes Anwendungsszenario, aber es wäre schön, wenn es eine Workaround-Lösung gäbe.
Das einzige mit Authentifizierung verbundene Thema bei RSS ist die Unterstützung für URL-basierte Basic-Authentifizierung wie https://user:password@www.example.com (wofür wir keine Unterstützung bieten) oder etwas Ähnliches wie die derzeitige Unterstützung für api_key und api_username in der URL.
Obwohl es schön gewesen wäre, die URL-basierte Authentifizierung vollständig abzuschaffen, ist der beste Weg, um weiterhin private RSS-Feeds zu unterstützen, diese Art der Authentifizierung nur für Themen-/Kategorie-Feeds zuzulassen. Später können wir dann auch Unterstützung für schreibgeschützte API-Schlüssel hinzufügen.
Das Problem besteht zudem darin, dass RSS-Reader in der Regel nur ein einzelnes URL-Feld zum Hinzufügen eines Feeds haben. Selbst wenn RSS Unterstützung für Header hätte, hätten die Reader keinen Ort, um Anmeldeinformationen in einen Header einzufügen.
Eine Idee, die sich auf einige der Abgrenzungsarbeiten von @david bezieht, wäre, einen User-API-Schlüssel zu erstellen, der eng auf einen einzigen RSS-Feed beschränkt ist. So wäre die Angriffsfläche gering, und in solchen Fällen, in denen wir einen extrem eingeschränkten User-API-Schlüssel haben, könnten wir dessen Verwendung ohne Header erlauben (eine Spalte in user_api_key, die angibt, dass dieser Schlüssel für die Authentifizierung GET verwenden darf).
Die Herausforderungen dabei sind:
Wir haben keinen Mechanismus, mit dem Benutzer User-API-Schlüssel generieren können. Wir müssten etwas für den RSS-Anwendungsfall entwickeln, was eine neue UX erfordern würde. Ich bin mir nicht sicher, wo wir das einfügen würden, vielleicht im Benutzerprofil – ich weiß es nicht.
Wir haben keinen Mechanismus, um die Berechtigung nur auf einen bestimmten RSS-Feed einzugrenzen, den wir hinzufügen müssten.
Wir haben kein Flag für „erlaubter User-API-Schlüssel
Ich habe WordPress und Discourse integriert, wobei WordPress für das Single Sign-On (SSO) zuständig ist. Ich generiere eine Seitenleiste mit aktuellen Beiträgen in WordPress, indem ich RSS-Feeds aus mehreren Kategorien über die API verwende. Daher würde ich die URL-Authentifizierungsmethode dafür gerne beibehalten. Andernfalls müsste ich mir die Hände schmutzig machen und ein benutzerdefiniertes Widget schreiben, um die Header-Authentifizierungsoption zu implementieren. Ich zähle mich also zu den wenigen Nutzern, die das unterstützen (+1).
Kann mir jemand sagen, ob dies derzeit unterstützt wird oder nicht?
Ich habe Schwierigkeiten, es zum Laufen zu bringen.
Wenn ich versuche, den API_KEY in der Abfragezeichenfolge zu verwenden, erhalte ich:
Sie sind nicht berechtigt, die angeforderte Ressource anzuzeigen. Der API-Benutzername oder der Schlüssel ist ungültig.
Das deutet darauf hin, dass zumindest die Abfragezeichenfolge gelesen wird.
Update:
OK, es funktioniert jetzt irgendwie. Es scheint, dass ein Teil der RSS-Feeds verfügbar ist, aber nicht alle? Wenn ich die API-Schlüssel-Einstellungen betrachte, scheint es, dass wir Zugriff auf Folgendes haben:
Lesen
/t/:slug/:topic_id.rssListen lesen
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssWeiß jemand, warum dies die grundlegenden Feeds /latest.rss und /top.rss ausschließt?
Es scheint, dass beim Abrufen des RSS-Feeds mit einem API-Schlüssel ein Accept-Header angegeben werden muss, um die richtigen Daten zu erhalten.
curl https://bbs.example.com/c/cat.rss?api_key=KEY, kann dies zu einer \u003c HTTP/1.1 404 Not Found-Seite führen.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \