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