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.
Non è necessario che le chiavi API siano ora negli header, @sam?
Sì, lo fanno! @blake, hai qualche idea su come le persone gestiranno i feed RSS privati nel mondo attuale? I browser o gli aggregatori RSS supportano header personalizzati per l’autenticazione?
È un caso d’uso piuttosto raro, ma sarebbe bello trovare una soluzione alternativa.
L’unica cosa relativa all’autenticazione in RSS è il supporto per l’autenticazione di base basata su URL, come https://user:password@www.example.com (che attualmente non supportiamo) o qualcosa di simile a quanto già supportiamo con api_key e api_username nell’URL.
Sebbene sarebbe stato ideale eliminare completamente l’autenticazione basata su URL, la strada da percorrere, per mantenere il supporto per i feed RSS privati, è consentire questo tipo di autenticazione solo per i feed di topic e categorie. In un secondo momento, potremo aggiungere anche il supporto per chiavi API in sola lettura.
Il problema è inoltre che i lettori RSS di solito dispongono di un unico campo URL per aggiungere un feed; quindi, anche se RSS supportasse gli header, i lettori non avrebbero un posto dove inserire le credenziali in un header.
Un’idea in questo senso, correlata ad alcuni lavori di definizione degli ambiti di @david, è quella di creare una chiave API utente strettamente limitata a un singolo feed RSS. In questo modo, la superficie di attacco sarebbe ridotta e, in casi come questo, dove disponiamo di una chiave API utente con ambito ultra-restrittivo, potremmo permetterne l’uso senza intestazioni (aggiungendo una colonna su user_api_key per indicare che questa chiave può essere utilizzata per l’autenticazione tramite GET).
Le sfide in questo caso sono:
Non abbiamo un meccanismo per generare chiavi API utente; dovremmo crearne uno per il caso d’uso RSS, il che comporterebbe una nuova UX. Non sono sicuro di dove inserirla, forse nel profilo utente, ma non lo so.
Non abbiamo un meccanismo per limitare l’ambito a un singolo feed RSS specifico, che dovremmo aggiungere.
Non abbiamo un flag per “chiave API utente consentita” tramite parametri GET nell’URL, che sarebbe necessario per questo.
Nel complesso, vedo questo come qualcosa che potremmo risolvere, ma probabilmente dovremmo considerare una o due settimane di lavoro per farlo funzionare perfettamente.
Il vantaggio è che parte di questo lavoro è qualcosa che vorremmo fare indipendentemente da RSS, ma lo svantaggio è che parte del lavoro è strettamente legato a RSS e ci sono pochissime persone che utilizzano questa funzione al giorno d’oggi.
Spetta a @codinghorror decidere come vogliamo dare priorità a questo.
Ho integrato WordPress con Discourse, con WordPress che gestisce l’SSO. Sto generando una barra laterale con i post recenti in WordPress utilizzando i feed RSS di diverse categorie tramite l’API, quindi mi piacerebbe molto mantenere il meccanismo di autenticazione tramite URL per questo scopo. Altrimenti, dovrei mettermi al lavoro per scrivere un widget personalizzato e provare a implementare l’opzione di autenticazione tramite header. Quindi, immagino di essere un +1 a favore delle poche persone che lo utilizzano.
Qualcuno può dirmi se al momento è supportato o no?
Sto facendo fatica a farlo funzionare.
Se provo a usare l’API_KEY nella stringa di query, ricevo:
Non sei autorizzato a visualizzare la risorsa richiesta. Il nome utente o la chiave API non sono validi.
Il che implica che sta tentando di leggere almeno la stringa di query.
Aggiornamento:
Ok, ho risolto in parte. Sembra che sia disponibile un sottoinsieme di feed RSS, ma non tutti? Dalle impostazioni della chiave API sembra che possiamo accedere a:
lettura
/t/:slug/:topic_id.rsslettura liste
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssQualcuno sa perché questo esclude i feed di base /latest.rss e /top.rss?
Sembra che per recuperare il RSS con la chiave API sia necessario specificare un header di accettazione per ottenere i dati corretti.
curl https://bbs.example.com/c/cat.rss?api_key=KEY, si potrebbe ottenere una pagina < HTTP/1.1 404 Not Found.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \