Hallo,
ich versuche seit einiger Zeit, einen Benutzer über eine externe ID gemäß der Dokumentation abzurufen:
https://docs.discourse.org/#tag/Users/paths/~1u~1by-external~1{external_id}.json/get
Bei allen Benutzern, die ich versuche, erhalte ich eine „404 nicht gefunden“-Meldung. Mit derselben URI, demselben API-Schlüssel und demselben Benutzernamen kann ich jedoch Kategorien und Gruppen abrufen. Haben Sie einen Tipp?
Mit freundlichen Grüßen,
Mark Pemburn
Blue Ocean Ideas
@pfaffman Ich verstehe deine Antwort nicht, sie enthält keine Antwort. Dieses Thema zeigt, wie man Informationen zu nicht dokumentierten Endpunkten findet. Dieser ist dokumentiert, und es ist einer der wenigen API-Aufrufe, die sich nicht so rückwärts entwickeln lassen, da dieser spezifische API-Endpunkt nie vom Ember-Frontend aufgerufen wird?
@mpemburn Es sollte funktionieren, die Dokumentation sieht korrekt aus. Die externe ID ist die ID in deiner Remote-Datenbank, die übergeben wird, wenn SSO aktiviert ist. Kannst du deinen Code teilen?
Hoppla. Meistens lautet die Antwort auf die Frage „Die API-Dokumentation ist fehlerhaft, wie kann ich …?“, was ich verlinkt habe. Bei genauerem Hinsehen wird schmerzhaft deutlich, dass etwas, das externe IDs betrifft, nicht über die Benutzeroberfläche zugänglich ist. Zum Glück für Mark achtest du genauer!
Theorie #1:
In den meisten Fällen (nicht immer) ist die externe ID eine Datenbank-ID und damit ein numerischer Wert. Sind Sie sicher, dass Ihre externe ID mark89 ist? Gibt SingleSignOnRecord.find_by(external_id: 'mark89') einen Datenbankdatensatz zurück?
Theorie #2:
Ihre Staging-Umgebung hat SSO nicht aktiviert, was normalerweise mit externen IDs einhergeht. Sind Sie sicher, dass externe IDs vorhanden sind?
Warten Sie… Ihre Header befinden sich in einem Cookie? Das ist nicht in Ordnung… es sollte so aussehen:
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, leider funktioniert das auch nicht.
Ich habe dieselbe Anfrage über das WordPress-Discourse-Plugin ausprobiert, und auch damit funktioniert es nicht, obwohl die Anfrage zum Abrufen eines Benutzers per E-Mail funktioniert. Ich dachte, es könnte ein Problem mit unserer Sandbox-Version von Discourse sein (damit habe ich bis jetzt getestet), also habe ich es an unserer Produktionsinstanz versucht, und das Ergebnis ist dasselbe. Ich bin mir nicht sicher, was ich jetzt tun soll, aber ich brauche das unbedingt zum Laufen.
Mark
Hast du meine beiden Theorien geprüft, die ich aufgeschrieben habe, bevor ich gesehen habe, dass du die Authentifizierungs-Header falsch sendest?
Theorie #1:
In den meisten Fällen (nicht immer) ist die externe ID eine Datenbank-ID und somit ein numerischer Wert. Bist du sicher, dass deine externe ID mark89 ist? Gibt SingleSignOnRecord.find_by(external_id: 'mark89') einen Datensatz in der Datenbank zurück?
Theorie #2:
Deine Staging-Umgebung hat SSO nicht aktiviert, was normalerweise mit externen IDs einhergeht. Bist du sicher, dass externe IDs vorhanden sind?
Richard,
Okay, die Sandbox ist also nicht mit SSO konfiguriert, aber die Produktion schon. Ich habe meinen Benutzereintrag in der Produktion geprüft, und ja, die externe ID ist gesetzt und handelt sich tatsächlich um eine numerische ID. Als ich mit den Produktionsanmeldedaten, der URI und der echten externen ID getestet habe, wurde derselbe 404-Fehler zurückgegeben.
Ach ja, und ich bin mir nicht sicher, wie ich SingleSignOnRecord.find_by(external_id: ‘mark89’) testen soll. Wo finde ich diese Funktion?
Mark
cd /var/discourse
./launcher enter app
rails c
SingleSignOnRecord.find_by(external_id: 'mark89')