Ciao,
Ho provato a ottenere un utente tramite ID esterno seguendo la documentazione:
https://docs.discourse.org/#tag/Users/paths/~1u~1by-external~1{external_id}.json/get
Ma ottengo sempre un errore “404 not found”, indipendentemente dall’utente che provo. Utilizzando lo stesso URI, chiave API e nome utente, riesco invece a recuperare categorie e gruppi. Hai qualche suggerimento?
Cordiali saluti,
Mark Pemburn
Blue Ocean Ideas
@pfaffman Non capisco la tua risposta, non contiene una risposta. Quella discussione spiega come scoprire gli endpoint non documentati. Questo invece lo è, ed è una delle pochissime chiamate API che non possono essere reverse-engineered in quel modo, dato che questo specifico endpoint API non viene mai chiamato dal frontend Ember?
@mpemburn Dovrebbe funzionare, la documentazione sembra corretta. L’ID esterno è l’ID nel tuo database remoto, che viene passato quando hai l’SSO abilitato. Puoi condividere il tuo codice?
Ops. Nella maggior parte dei casi, la risposta a “la documentazione dell’API è rotta, come faccio a…” è proprio quello a cui ho linkato. Guardando più attentamente, è dolorosamente evidente che qualcosa che coinvolge ID esterni non può essere accessibile tramite l’interfaccia utente. Fortunatamente per Mark, tu stai prestando più attenzione!
Teoria #1:
Nella maggior parte dei casi (non sempre) l’ID esterno è un ID di database e quindi un valore numerico. Sei sicuro che il tuo ID esterno sia mark89? SingleSignOnRecord.find_by(external_id: 'mark89') restituisce un record del database?
Teoria #2:
Il tuo sito di staging non ha SSO abilitato, il che solitamente va di pari passo con gli ID esterni. Sei sicuro che gli ID esterni siano presenti?
Aspetta… i tuoi header sono in un cookie? Non va bene… dovrebbe essere così:
curl --location --request GET 'https://discourse.example.com/u/by-external/mark89.json'
--header 'Accept: application/json'
--header 'Api-Key=[Api-Key]'
--header 'Api-Username=system'
Ah, purtroppo nemmeno questo funziona.
Ho provato la stessa richiesta usando il plugin Discourse per WordPress e non funziona nemmeno con quello, sebbene la richiesta per ottenere un utente tramite email funzioni. Pensando che potesse essere un problema della nostra versione sandbox di Discourse (con cui ho fatto i test fino a questo momento), l’ho provata anche sulla nostra istanza di produzione, ma la situazione è la stessa. Non so cosa fare da qui, ma ho davvero bisogno che questo funzioni.
Mark
Hai controllato le mie due teorie che ho scritto prima di vedere che stavi inviando le intestazioni di autenticazione in modo errato?
Teoria n. 1:
Nella maggior parte dei casi (non sempre) l’ID esterno è un ID di database e quindi un valore numerico. Sei sicuro che il tuo ID esterno sia mark89? SingleSignOnRecord.find_by(external_id: 'mark89') restituisce un record di database?
Teoria n. 2:
Il tuo sito di staging non ha SSO abilitato, il che di solito va di pari passo con gli ID esterni. Sei sicuro che gli ID esterni siano presenti?
Richard,
Ok, quindi l’ambiente sandbox non ha l’SSO configurato, ma quello di produzione sì. Ho controllato il mio record utente su produzione e sì, l’external ID è impostato ed è, di fatto, un ID numerico. Quando ho eseguito il test con le credenziali di produzione, l’URI e l’external ID reale, ho ricevuto lo stesso errore 404.
Ah, e non sono sicuro di come testare SingleSignOnRecord.find_by(external_id: ‘mark89’). Dove si trova questa funzionalità?
Mark
cd /var/discourse
./launcher enter app
rails c
SingleSignOnRecord.find_by(external_id: 'mark89')