Ich sehe diese Meldung, wenn ich versuche, Discourse_id auf meinem Testsystem (3.6.0.beta2-latest) zu aktivieren:
enable_discourse_id: Sie müssen Discourse ID-Anmeldeinformationen ('discourse_id_client_id' und 'discourse_id_client_secret') konfigurieren, bevor Sie diese Einstellung aktivieren.
Ich verwende hier einen lokalen Oauth-Server für OIDC (keycloak). Vielleicht stören sich die beiden Methoden gegenseitig??
Ich glaube nicht, dass es OIDC beeinträchtigt, aber wenn Ihre Instanz nicht im Internet verfügbar ist, funktioniert die ID-Registrierung nicht. Der Discourse ID-Identitätsanbieter verfügt über einen Verifizierungsmechanismus für die Discourse-Instanzen, die den Registrierungsprozess initiieren.
Die Testinstanz ist unter forum2.netzwissen.de online.
Ich sehe dieselbe Meldung auf 2 Instanzen, von denen keine eine andere OAuth-Verbindung hat.
Ich habe dies in ein separates Thema verschoben… sehen Sie Fehler in /logs auf Ihrer Instanz? Dort sollten mehr Details ausgegeben werden, was während des Registrierungsprozesses im Hintergrund nicht funktioniert.
Ich würde es gerne von der technischen Seite her etwas besser verstehen.
Auf meinen Instanzen verwende ich OIDC-Authentifizierung mit einem externen Identitätsanbieter (Keycloak 26). Discourse ID sieht sehr ähnlich aus; es ist nur ein anderer IDP-Server, der von Discourse.org gehostet wird. Und die Fehlermeldungen (client ID und secret fehlen) erinnern auch an den klassischen OAuth-Flow. Bedeutet das, dass Discourse ID als zusätzlicher IDP-Authentifizierungspfad aktiviert wird? Denn nur dann wäre es für meinen Anwendungsfall nützlich. ???
nur diese eine, aber relativ regelmäßig, sodass sie nichts mit dem Thema zu tun hat.
Nachricht (2 Kopien gemeldet)
Sidekiq verbraucht zu viel Speicher (verwendet: 503,02 MB) für 'rpg-foren-app', Neustart
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
'
Ja, korrekt, Discourse ID ist ein weiterer IDP.
@Tealk der Sidekiq-Fehler ist nicht relevant. Können Sie bitte den Commit-Hash für Ihre Instanz mitteilen?
Sicher, hier: 3.5.1 (c96aeda334)
ok. Dann bräuchte ich eine Client-ID bei Ihrem IDP (für den Public-Access-Workflow) oder eine Client-ID und ein Client-Geheimnis (für den Confidential-Access-Workflow). Eine weitere Option: Fügen Sie die Discourse-ID als externen Identitätsbroker zum lokalen IDP hinzu. Für beide Varianten wären noch ein paar Informationen erforderlich 
…
Ja, jede Discourse-Instanz registriert sich (im Hintergrund) und richtet eine Client-ID und ein Secret ein.
Wenn ich mir eure Instanz jetzt ansehe, sehe ich http/https-Fehler. Damit die ID funktioniert, muss die Seite unter https laufen. Das ist wahrscheinlich euer Problem.
@Tealk stellt sicher, dass eure Seite auch unter https richtig funktioniert.
Ich wüsste nicht, was ich verbessern könnte:
Funktioniert Discourse ID bereits in Foren, die den stabilen Branch verwenden? Ich dachte, die Funktion würde erst nach der Veröffentlichung im August hinzugefügt werden.
Ah, in der Tat, wenn Sie sich im stable-Kanal befinden, @Tealk, müssen Sie auf die nächste stabile Version warten, damit Discourse ID für Sie verfügbar ist.
Beachten Sie auch, dass DiscourseConnect eine separate Funktion ist.
Okay, das ist verwirrend auf der „Was ist neu“-Seite. Wäre es möglich, hinzuzufügen, ab welcher Version ein Feature enthalten ist?
Das ist ein guter Punkt. Ich habe den „Was gibt’s Neues“-Feed jetzt so aktualisiert, dass er nur diesen Eintrag für Instanzen enthält, die nicht auf „stable“ laufen (und die den Commit in latest haben, der die Discourse-ID freischaltet). Wenn Sie Ihren „Was gibt’s Neues“-Feed aktualisieren, sollten Sie diesen Eintrag auf Ihrer Instanz auf „stable“ nicht mehr sehen.
Ich habe die Einstellungen bereits in den Einstellungen, sollte die Einstellung verfügbar sein, bevor sie implementiert wird?
Die enable_discourse_id-Site-Einstellung sollte bei Ihnen nicht vorhanden sein. (Stellen Sie sicher, dass Sie sie nicht mit enable_discourse_connect verwechseln, das ist etwas anderes.)
Jetzt, da ich Ihre Instanz sehe, sehe ich HTTP/HTTPS-Fehler. Damit die ID funktioniert, muss die Website über HTTPS erreichbar sein. Das ist wahrscheinlich Ihr Problem.
… interessant, aber ich verstehe nicht warum. Vielleicht haben wir hier eine konzeptionelle Lücke: Die Discourse-Container befinden sich hinter einem SSL-Beschleuniger, nur über HTTPS erreichbar. Aber das gilt für die Standardverbindung, die von „außen“ nach „innen“ kommt. Im OAuth-Anwendungsfall startet der Discourse-Container die Verbindung von „innen“ zum IDP, der sich „außen“ befindet. Ich sehe keine Möglichkeit, diese Verbindung zur Discourse-ID zu konfigurieren und sie zu zwingen, „HTTPS“ zu sein.
Wenn ich dies mit den klassischen OIDC-Einstellungen vergleiche, die für die OAuth-Konfiguration mit meinem eigenen IDP verwendet werden: Dort haben wir eine Einstellung für das „OpenID Connect Discovery Document“
https://....realms/[realm-name]/.well-known/openid-configuration
Ich denke, wir brauchen etwas Ähnliches für die Discourse-ID, um Probleme mit fehlenden HTTPS-Verbindungen zu vermeiden. PS. Meine Testinstanz hat 3.6.0.beta2-latest, Commits · discourse/discourse · GitHub
