Ich habe im Moment keine lokale Discourse-Installation, daher bin ich mir nicht sicher, wie sehr ich helfen kann.
Die 404-Antwort lässt mich fragen, ob Discourse Connect auf Ihrer Discourse-Site tatsächlich aktiviert ist:
Es scheint, dass Sie dies mit einer lokalen Angular-App und einer Produktions-Discourse-Site testen. Ich würde erwarten, dass dies immer noch funktioniert, aber möglicherweise verursacht es ein Problem. Sie sollten definitiv in der Lage sein, eine andere Antwort als eine 404 zu erhalten.
und ich habe auch eine Produktions-Testseite, die auf der übergeordneten Domain dieser Discourse-Site gehostet wurde. Wenn du dir diesen [Link entfernt] ansehen kannst,
um den Produktionsablauf zu testen, habe ich die Discourse Connect-URL auf „https://domainsite.com/login“ aktualisiert. Melde dich gerne mit dem Google-Anbieter an und teste es. Im Konsolenprotokoll der Inspektion siehst du den Fehler und die von mir ausgegebene Antwort, die 404 ist.
Da ich gerade die Proof of Concept (POC) durchführe, könntest du mir deine E-Mail-Adresse mitteilen, damit ich dich zum Administrator ernennen kann, um die Konfigurationen auf meiner Discourse-Site genau zu untersuchen. Nochmals vielen Dank für deine Zeit und Hilfe.
Der einzige Teil, bei dem ich mir nicht sicher bin, ist das SIG und SSO. Mache ich es im Code richtig?
Abgesehen von diesem Teil. Den API-Schlüssel habe ich mit beidem versucht, sowohl für jeden als auch nur für das System generiert, die Ergebnisse sind gleich.
Wenn möglich, bitte ich um ein funktionierendes Beispiel für Postman oder Angular-basierten Code.
Mir ist das entgangen, als ich mir den Screenshot Ihres Codes zum ersten Mal angesehen habe:
mode: 'no-cors'
Ich bin nicht mit Angular-Apps vertraut, aber es sieht so aus, als ob Sie eine authentifizierte API-Anfrage von einem Client an Discourse stellen möchten. Ich bin mir nicht sicher, wo dies im Discourse-Code geschieht, aber meines Wissens blockiert Discourse Admin-API-Anfragen, die vom Client aus gestellt werden. Dies liegt daran, dass es keine Möglichkeit gibt, die Anfrage zu stellen, ohne den API-Schlüssel auf dem Client preiszugeben. In diesem Zusammenhang sollten Sie Ihren API-Schlüssel jetzt ändern.
Danke, dass Sie darauf hingewiesen haben.
Es fühlt sich an, als ob wir einen Schritt weiter gehen.
Ich versuche auch, die Anfrage von Postman aus zu senden.
Wenn Sie denken, dass der Block von der Client-Seite “mode: ‘no-cors’” da Discourse den Aufruf mit API-Schlüsseln vom Frontend nicht akzeptiert, dann sollte es in Ordnung sein, ihn von Postman zu senden, ist das richtig? Aber das Ergebnis ist dasselbe
Es muss etwas falsch sein, es scheint sehr nah am Grundproblem zu sein.
Ich habe sogar versucht, einen Server zu starten und dann den Server auszulösen, um die Anfrage mit dem API-Schlüssel auf der Serverseite zu senden, was das gleiche Ergebnis liefert. Das gibt mir das Gefühl, dass mir einige Konfigurationen auf der Discourse-Seite fehlen.
Es ist eine gute Idee, dies über Postman oder sogar einfach über die Befehlszeile zum Laufen zu bringen. Auf dem von Ihnen geposteten Screenshot scheint es, als hätten Sie den api-username und den api-key im Body der Anfrage. Diese Parameter müssen im Header der Anfrage stehen. Der Body der Anfrage sollte die sig- und sso-Schlüssel/Wert-Paare enthalten. Wenn es hilft, hier ist, wie das WP Discourse-Plugin damit umgeht: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub .
Wow! Los geht’s,
jetzt funktioniert es!
1000 Dank @simon
Das Problem war genau das, was Sie erwähnt haben:
sso und sig sollten die einzigen beiden Schlüsselpaare im Body sein
api-key und api-username sollten in den Headern sein
Wie wird sich das verhalten, wenn ich dies auf einer Website aktiviere, die derzeit kein external_id verwendet? Können Benutzer nur anhand ihrer E-Mail-Adresse angemeldet werden?
Im Allgemeinen, da email und external_id die 2 obligatorischen Felder in der Nutzlast sind, könnten Sie bitte klären, wie sie auf der Discourse-Seite verwendet werden (beim Empfang der Nutzlast von der authentifizierenden Website), um herauszufinden, bei welchem Benutzerkonto angemeldet werden soll?
Was passiert, wenn während der Benutzererstellung keine externe ID mit der E-Mail-Adresse verknüpft war? Wird dann die E-Mail-Adresse verwendet und die externe ID für zukünftige Anmeldungen mit dieser E-Mail-Adresse verknüpft?
Was passiert, wenn es eine Diskrepanz zwischen email und external_id gibt (jeder ist mit einem anderen Discourse-Konto verknüpft)? Wird dann external_id oder email verwendet, um herauszufinden, bei welchem Benutzer angemeldet werden soll? Oder wird ein Fehler ausgelöst?
Ich glaube, Ihre Hauptfrage bezieht sich auf das Feld external_id. Sie müssen ein Feld external_id in der DiscourseConnect-Nutzlast festlegen. Der Wert des Feldes sollte eine Zeichenfolge sein, die mit dem Benutzer verknüpft ist und sich niemals ändert. Ich gehe davon aus, dass Ihre Anwendung eine Benutzertabelle hat. Der Primärschlüssel für den Eintrag eines Benutzers in dieser Tabelle wäre gut geeignet, um den Wert des Feldes external_id zu verwenden.
Wenn ein Benutzer ein Konto in Discourse erstellt hat, bevor Sie die DiscourseConnect-Authentifizierung von Ihrer Website aus hinzugefügt haben, versucht Discourse beim ersten Mal, wenn sich der Benutzer über DiscourseConnect bei Discourse anmeldet, den Benutzer anhand der E-Mail-Adresse zu finden, die sich in der DiscourseConnect-Nutzlast befindet. Nach dem Auffinden des Benutzers wird ein Eintrag in der Discourse-Datenbank hinzugefügt, der die external_id aus der DiscourseConnect-Nutzlast enthält. Wenn sich der Benutzer das nächste Mal anmeldet, wird er anhand der external_id und nicht anhand der E-Mail-Adresse gefunden. (Beachten Sie, dass dies nicht funktioniert, wenn Sie den Parameter require_activation in der DiscourseConnect-Nutzlast auf true setzen.)
Discourse verfügt über gute Fallback-Mechanismen für die meisten Sonderfälle. Es gibt Probleme im Zusammenhang mit Benutzern, die mehrere Konten und E-Mail-Adressen haben, die Fehler auslösen können. Einige Details zur Behandlung dieser Fälle finden Sie hier: Debuggen und Beheben häufiger DiscourseConnect-Probleme.
Wir verwenden DiscourseConnect seit mehreren Jahren erfolgreich mit WordPress als Provider und haben die Konfigurationen von Discourse oder WP nicht geändert. Heute bemerke ich ein neues Verhalten.
Wenn ich mich abmelde, wurde ich früher zur WordPress-Anmeldeseite weitergeleitet. Jetzt werde ich zur Discourse-Anmeldeseite weitergeleitet. Wenn ich versuche, mich über den Discourse-Bildschirm anzumelden, erhalte ich eine unbekannte Fehlermeldung, aber der Punkt ist, dass ich gar nicht dort sein sollte – ich sollte mich auf der WP-Anmeldeseite befinden.
Beachten Sie, dass lokale Anmeldungen aktiviert sind (ich weiß nicht warum, da ich WP verwende). Wenn ich lokale Anmeldungen deaktiviere und versuche, mich anzumelden, wird angezeigt, dass keine Anmeldemethoden verfügbar sind. Ich schätze, es mag meine WP-Verbindung nicht, aber ich habe die Konfigurationen auf keiner Seite geändert. Ich habe bestätigt, dass Discourse Connect aktiviert ist, die Connect-URL korrekt ist und das Geheimnis auf beiden Seiten dasselbe ist.
Aktuell mit 3.5.0.beta5-dev. Auch das WP Discourse Plugin ist auf dem neuesten Stand.
Wir verwenden ebenfalls DiscourseConnect und haben das gleiche Problem.
Wir haben es seit einigen Jahren am Laufen und alles funktionierte reibungslos. Heute auf 3.5.0.beta8-dev [e91024a221] aktualisiert.
Grundsätzlich fügt der Callback vom SSO-System zur Discourse-URL https://discourse.domain.ext/login hinzu und wir haben den gleichen Bildschirm wie @markschmucker.
Wir haben auch festgestellt, dass wir beim Klicken auf das Header-Logo auf https://discourse.domain.ext/ landen und der Login erfolgreich ist (nur ein Klick auf einen Button ist nötig).
Es scheint, dass in der vorherigen Version der Session Controller anders funktionierte und wahrscheinlich verstand, dass der Aufruf von externem SSO initiiert wurde und ihn auf die richtige Weise behandelte.
Ich habe bemerkt, dass @zogstrip im letzten Monat einige Änderungen vorgenommen hat, die (nicht zu 100 % sicher) mit dem Fehlverhalten zusammenhängen könnten.
Bis jetzt haben wir einen Workaround in der Callback-Methode angewendet, der /login zur Discourse-URL hinzufügt und alles scheint ordnungsgemäß zu funktionieren.
Wenn ich etwas übersehe, wie z. B. Dokumentationen, die Ratschläge zu einer potenziell störenden Änderung in diesem Codeabschnitt gaben, lassen Sie es mich bitte wissen.
Vielen Dank für Ihre Hilfe dabei, @zogstrip . Leider verliere ich die Möglichkeit, eine „Willkommensseite“ für anonyme Benutzer zu haben, wenn ich „sofortige Authentifizierung“ aktiviere.
Es scheint nicht möglich zu sein, einen Namen oder eine avatar_url über DiscourseConnect SSO zu entfernen. Ich habe versucht, die Felder auf einen leeren String zu setzen (bestätigt z. B. avatar_url= landet im Base64-SSO-Parameter), aber ich vermute, der Code ignoriert leere Felder.
Namen und Bilder sind in meinem System optional, aber so wie es jetzt funktioniert, können sie, sobald sie gesetzt sind, nie wieder entfernt, sondern nur ersetzt werden. Gibt es eine Chance, dass ich etwas falsch mache? (Wenn nicht, könnte das vielleicht behoben werden?)
[Edit]: Ich hatte bereits nach einer Antwort gesucht, aber natürlich, sobald ich das oben gepostet habe, habe ich versucht, nach anderen Schlüsselwörtern zu suchen und fand Allow name removal using SSO - #9 by mentalstring. Habe dafür gevotet, aber mache mir keine allzu großen Hoffnungen.
Ich habe dasselbe Login-Redirect-Problem, das @markschmucker, @jimkleiber und @marco.palumbo oben beschreiben. Ich habe es vor ein paar Wochen entdeckt und wusste, dass es im Mai noch korrekt funktioniert hatte. Wenn ich lese, was Sie oben darüber gesagt haben, bin ich überzeugt, dass es sich um eine Regression in Discourse handelt, die im Mai in einem Update eingeführt wurde, da es uns alle zur gleichen Zeit getroffen hat, wir alle funktionierenden SSO-Code hatten und wir keinen SSO-Code gemeinsam haben.
Ich habe einen Fehlerbericht veröffentlicht, in der Hoffnung, dass wir dies beheben können.
