Fehlerhafte DC SSO-Verbindung verlangsamt den Administrator mit einem Timeout

Unterstützung WordPress
1

Ich habe Discourse Connect SSO mit dem offiziellen Plugin eingerichtet, sodass sich meine WP-Benutzer bei Discourse anmelden können, ohne sich dort erneut registrieren zu müssen. Es funktioniert alles gut, außer dass jede einzelne Anfrage an das WP-Dashboard (Admin-Bereich) um 10 Sekunden verzögert wird, aufgrund eines Timeouts, den ich nur über das Query Monitor Plugin entdeckt habe.

https://{unsere-forum-adresse}/site.json cURL-Fehler 28: Verbindungstimeout nach 10001 ms

WPDiscourse\Admin\MetaBox->discourse_request()
wp-content/plugins/wp-discourse/lib/plugin-utilities.php:516
WPDiscourse\Admin\MetaBox->get_discourse_categories()
wp-content/plugins/wp-discourse/lib/plugin-utilities.php:273
WPDiscourse\Admin\MetaBox->setup_options()
wp-content/plugins/wp-discourse/admin/meta-box.php:49
do_action('admin_init')
wp-includes/plugin.php:517

Plugin: wp-discourse

Auch wenn es funktionieren würde, warum ist ein solcher Aufruf überhaupt notwendig? Wie kann ich ihn deaktivieren?

Forum und Website befinden sich auf separaten Servern. Es gibt kein Cloudflare. SSL ist Let’s Encrypt. Auf Staging hatte es dieses Problem nicht. Ich bin zum Live-System gewechselt, habe einen neuen API-Schlüssel und ein neues Secret erstellt und versucht, dies zu beheben, aber es hat nicht funktioniert.

Das Plugin sagt Sie sind nicht mit Discourse verbunden. Überprüfen Sie, ob Ihre Verbindungseinstellungen korrekt sind. Wenn das Problem weiterhin besteht, aktivieren Sie die Verbindungsprotokolle und überprüfen Sie die Protokolle. …aber das bin ich, da Benutzer sich nahtlos im Forum anmelden können, indem sie einfach auf einen Link klicken, der die Adresse enthält.

Die Protokolle in WP sagen:


[2024-10-31 10:54:47] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Eine ungültige Antwort wurde von Discourse zurückgegeben","http_code":"","http_body":""}

Ich dachte, diese seltsame WP-Sicherheitsfunktion würde es behindern, also habe ich Folgendes hinzugefügt, aber es hat auch nichts gebracht:


add_filter('http_request_host_is_external', [$this, 'mark_discourse_api_url_external'], 10, 3);

function mark_discourse_api_url_external($is_external, $host, $url)
{
    if ($host === "{unsere-forum-adresse}") {
        return true; // Erlaubt die Anfrage, indem angezeigt wird, dass der Host extern IST
    }

    return $is_external;
}
2

Hallo @Firsh,

Dieser Aufruf an Ihre /site.json wird vom Wordpress-Plugin benötigt, um Informationen über Ihr Discourse abzurufen.

Das bedeutet, dass Sie nicht richtig verbunden sind, und auch wenn alles zu funktionieren scheint, würde ich mich nicht darauf verlassen, dass es so bleibt.

Darauf müssen wir uns konzentrieren. Könnten Sie mitteilen, welche Art von Schlüssel Sie erstellt haben? Als Referenz stellen Sie bitte sicher, dass Sie die Richtlinien hier befolgen:

2 „Gefällt mir“
3

Ich glaube nicht, dass es am Schlüssel liegt. Ich habe es vorher mit dem Schlüssel der Staging-Website versucht, und der neue sagt “nie benutzt”. Wenn ich einen Testaufruf wp_remote_request() an die Homepage meines Forums mache, schlägt dieser ebenfalls fehl (Timeout). Ich habe es für “jeder Benutzer” und “global” eingerichtet.

Ja, aber warum ständig auf jeder nicht verwandten Admin-Seite? Einmal, wenn es benötigt wird, würde ausreichen. Ich habe herausgefunden, woher es kommt, und es ist function get_discourse_categories(), und dies ist fest in add_action( 'admin_init', array( $this, 'setup_options' ) ); einprogrammiert. Ich möchte nicht, dass mein WP etwas über Kategorien im Forum weiß, ich benutze keine Veröffentlichungs-/Kommentarfunktionen, ich brauche nur die Anmeldung, die bereits funktioniert.

Ich habe auch eine Anfrage an die Homepage des Forums mit wp_remote_request() gemacht, und diese schlägt ebenfalls fehl (Timeout). Andere zufällige Websites sind zugänglich.

4

Ich verstehe, dass Sie die Anfrage an /site.json als unnötig empfinden. Ohne eine erfolgreiche Verbindung zu Ihrem Discourse funktioniert das WordPress-Plugin jedoch nicht zuverlässig für Sie, daher sollten wir unabhängig davon herausfinden, warum das nicht funktioniert.

  1. Können Sie weitere Unterschiede zwischen Ihrer Staging- und Produktionsumgebung feststellen?
  2. Können Sie die WP Discourse Log-Metadateien Ihrer Staging- und Produktionsinstanzen teilen?
  3. Können Sie Links zu Ihren WordPress- und Discourse-Instanzen teilen?
1 „Gefällt mir“
5

Ja, aber es ist eine private, nur für Mitglieder zugängliche Seite und ein Forum auf Ungarisch.

Forum: https://forum.intelligensbefektetok.hu/
Seite: https://intelligensbefektetok.hu/

Mein Staging war eine exakte manuelle Kopie, obwohl sie in Docker in einer VM lief. Die Produktion wird nicht von mir verwaltet, und ich habe keine Ahnung, welche Art von Hosting es ist, aber wir hatten noch nie Probleme und es war vorher ziemlich schnell.

Ich habe gerade Folgendes versucht:

  • Die Option sslverify = false in der Funktion discourse_request
  • Und ich habe einen CNAME (Alias) auf Cloudflare auf einer meiner anderen Domains erstellt, um hinter den Kulissen auf den Host des Forums zu verweisen („bessere“ SSL und der Host ist anders, um eine Art Loopback-Beschränkung in der Firewall des Live-Site-Hosts auszuschließen): https://ibkforum.stateofbliss.us, aber es gibt die gleiche Zeitüberschreitung, während Tests von Staging aus einwandfrei funktionieren. Es leitet zu der Hauptseite weiter, wenn man nicht angemeldet ist.
  • Ich benutze dieses winzige Plugin, um die Anfragen zu überprüfen: https://wphive.com/plugins/wp-remote-request-check/

object(WP_Error)#5757 (3) { [“errors”]=> array(1) { [“http_request_failed”]=> array(1) { [0]=> string(59) “cURL error 28: Connection timed out after 5000 milliseconds” } } [“error_data”]=> array(0) { } [“additional_data”:protected]=> array(0) { } }

  • Andere WP-Seiten; dieses Forum; die Live-Seite, wenn sie eine Anfrage an sich selbst sendet, funktionieren alle einwandfrei.

Staging WP-Log:

[2024-10-31 13:09:08] connection.INFO: check_connection_status.valid_scopes
[2024-10-31 13:09:19] connection.INFO: check_connection_status.successful_connection
[2024-10-31 13:09:19] connection.INFO: check_connection_status.valid_scopes

Live-Site-Logs sind die gleichen wie in meiner OP:

[2024-10-31 13:12:32] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""}

Wenn direkt im Browser aufgerufen, funktioniert dies:
https://forum.intelligensbefektetok.hu/site.json

Danke für die Hilfe übrigens.

6

Meinen Sie WordPress-Produktion oder Discourse-Produktion? Ist es möglich, dass es in Ihrer Discourse-Produktionsumgebung etwas gibt, das Weiterleitungen durchführt und/oder Header in Anfragen ändert (oder entfernt)?

Wenn Sie diese Meta-Dateien beider Instanzen teilen könnten, wäre das hilfreich. Klicken Sie im Admin-Panel „Protokolle“ auf „Meta anzeigen“.

Das ist wahrscheinlich das grundlegende Problem. Wenn Ihr WordPress Ihre Discourse überhaupt nicht sehen kann, wird die Verbindung nicht funktionieren. Wenn Sie diese Konnektivität einfach testen können, würde ich das weiterhin tun, während Sie Änderungen an der Netzwerkschicht Ihres Forums vornehmen, bis Sie eine 403 (d. h. nicht autorisiert) erhalten.

Mein Gefühl sagt mir, dass dies ein Problem auf Netzwerkebene ist, vielleicht eine Weiterleitung oder eine Firewall.

7

Es gibt kein Staging-Discourse, beide Seiten verwenden dasselbe Live-Discourse (gleiche Benutzer-IDs usw.). Ich habe dies in einem anderen Thread angesprochen und es sollte in Ordnung sein. Die Netzwerkschicht des Forums ist sehr einfach, gehostet auf Hetzner, das offizielle Docker-Ding auf einem VPS, und das Forum wurde kaum genutzt oder über einige visuelle Elemente hinaus angepasst. Mir sind keine Einstellungen bekannt, die verhindern könnten, dass es erreicht wird. Ich habe ein Ticket beim WP-Hosting-Unternehmen erstellt, um zu sehen, ob sie herausfinden können, warum die Verbindungen fehlschlagen, da ich mir über deren ungewöhnliche Einrichtung mehr Sorgen mache.

Was mich interessiert, ist, dass die bloße Tatsache, dass das Forum WP erreichen kann (nicht umgekehrt), für ein funktionierendes SSO “ausreicht”. Außer dem Abmelden von Benutzern aus dem Forum.

Logs (Live-Site lädt eine 0-Byte-ZIP-Datei herunter).

8

Ja, ich würde zuerst das Ergebnis abwarten, sonst drehen wir uns hier vielleicht im Kreis. Die grundlegende Frage ist, warum eine Standard-WP-Anfrage Ihr Forum nicht erreichen kann.