La connexion DC SSO échouée ralentit l'administrateur avec un délai d'expiration

Soutien WordPress
1

J’ai configuré Discourse Connect SSO à l’aide du plugin officiel, de sorte que mes utilisateurs WP se connectent à Discourse sans avoir à enregistrer un nouvel utilisateur là-bas. Tout fonctionne bien, sauf que chaque requête du tableau de bord WP (zone d’administration) est ralentie de 10 secondes en raison d’un délai d’attente que j’ai découvert uniquement via le plugin Query Monitor.

https://{notre-adresse-forum}/site.json Erreur cURL 28 : Délai de connexion expiré après 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

Même si cela fonctionnait, pourquoi un appel comme celui-ci est-il nécessaire en premier lieu ? Comment puis-je le désactiver ?

Le forum et le site sont sur des serveurs séparés. Il n’y a pas de Cloudflare. SSL est letsencrypt. Cela ne posait pas de problème sur staging. Je suis passé en production, j’ai créé une nouvelle clé API et un nouveau secret, j’ai essayé de résoudre ce problème mais cela n’a pas fonctionné.

Le plugin indique Vous n’êtes pas connecté à Discourse. Vérifiez que vos paramètres de connexion sont corrects. Si le problème persiste, activez les journaux de connexion et consultez les journaux. … mais je le suis, car les utilisateurs peuvent se connecter de manière transparente au forum en cliquant simplement sur un lien contenant son adresse.

Les journaux dans WP indiquent :


[2024-10-31 10:54:47] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Une réponse invalide a été renvoyée par Discourse","http_code":"","http_body":""}

Je pensais que cette chose étrange de sécurité WP la bloquait, j’ai donc ajouté ceci mais sans succès non plus :


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 === "{notre-adresse-forum}") {
		return true; // Autoriser la requête en indiquant que l'hôte EST externe
	}

	return $is_external;
}
2

Salut @Firsh,

Cet appel à votre /site.json est nécessaire pour que le plugin Wordpress récupère des informations sur votre Discourse.

Cela signifie que vous n’êtes pas correctement connecté, et même si les choses semblent fonctionner, je ne parierais pas sur leur bon fonctionnement à long terme.

C’est sur cela que nous devons nous concentrer. Pourriez-vous partager quel type de clé vous avez créé ? Pour référence, assurez-vous de suivre les directives à ce sujet ici :

2 « J'aime »
3

Je ne pense pas que ce soit la clé. J’ai essayé avec la clé du site de staging auparavant, et la nouvelle indique “jamais utilisée”. Lorsque j’essaie un appel de test wp_remote_request vers la page d’accueil de mon forum, cela expire également. Je l’ai configuré pour “chaque utilisateur” et “global”.

Oui, mais pourquoi tout le temps sur chaque page d’administration non liée ? Une fois quand c’est nécessaire suffirait. J’ai trouvé d’où cela vient et c’est function get_discourse_categories() et c’est codé en dur dans add_action( 'admin_init', array( $this, 'setup_options' ) ); Je ne veux pas que mon WP connaisse les catégories du forum, je n’utilise aucune fonctionnalité de publication/commentaire, j’ai juste besoin de la connexion, qui fonctionne déjà.

J’ai également effectué une requête vers la page d’accueil du forum en utilisant wp_remote_request() et cela expire également. D’autres sites aléatoires sont accessibles.

4

Je comprends que vous trouvez la requête vers /site.json inutile, cependant, sans une connexion réussie à votre Discourse, le plugin Wordpress ne fonctionnera pas de manière fiable pour vous, nous devrions donc trouver pourquoi cela ne fonctionne pas de toute façon.

  1. Pouvez-vous penser à une autre différence entre votre environnement de staging et de production ?
  2. Pourriez-vous partager les fichiers méta du journal WP Discourse de vos instances de staging et de production ?
  3. Pourriez-vous partager les liens vers vos instances Wordpress et Discourse ?
1 « J'aime »
5

Oui, mais c’est un site et un forum privés réservés aux membres en hongrois.

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

Ma staging était une copie exacte faite manuellement, bien qu’exécutée dans Docker dans une VM. La production n’est pas gérée par moi, et je n’ai aucune idée du type d’hébergement, mais nous n’avons jamais eu de problèmes et c’était assez rapide avant cela.

J’ai essayé juste maintenant :

  • L’option sslverify = false dans la fonction discourse_request
  • Et j’ai créé un CNAME (alias) sur Cloudflare sur un autre de mes domaines pour pointer vers l’hôte du forum en coulisses (“meilleur” SSL et l’hôte est différent, pour exclure une sorte de restriction de bouclage dans le pare-feu de l’hôte du site live) : https://ibkforum.stateofbliss.us mais cela expire de la même manière, alors que les requêtes de test depuis la staging fonctionnent bien. Il redirige vers le site principal lorsqu’il n’est pas connecté.
  • J’utilise ce petit plugin pour vérifier les requêtes : 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) { } }

  • D’autres sites WP ; ce forum ; le site live lors d’une requête vers lui-même, tout fonctionne bien.

Journal de la staging WP :

[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

Les journaux du site live sont les mêmes que dans mon 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":""}

Lorsqu’il est chargé directement dans le navigateur, cela fonctionne :
https://forum.intelligensbefektetok.hu/site.json

Merci pour votre aide au passage.

6

Voulez-vous dire la production de Wordpress ou la production de Discourse ? Est-il possible qu’il y ait quelque chose dans votre environnement de production Discourse qui effectue des redirections et/ou modifie (ou supprime) des en-têtes dans les requêtes ?

Si vous pouviez partager ces fichiers meta des deux instances, cela aiderait. Cliquez sur “Voir Meta” dans le panneau d’administration “Journaux”.

C’est probablement le problème fondamental. Si votre Wordpress est incapable de voir votre Discourse du tout, la connexion ne fonctionnera pas. Si vous êtes en mesure de tester facilement cette connectivité, continuez à le faire tout en apportant des modifications à la couche réseau de votre forum jusqu’à ce que vous obteniez un 403 (c’est-à-dire non autorisé).

Mon instinct me dit qu’il s’agit d’un problème de couche réseau, peut-être une redirection ou un pare-feu.

7

Il n’y a pas de Discourse de staging, les deux sites utilisent le même Discourse en direct (mêmes identifiants utilisateur, etc.). J’ai posé la question dans un autre fil de discussion et cela devrait aller. La couche réseau du forum est très simple, hébergée sur Hetzner, le truc Docker officiel dans un VPS, et le forum a à peine été utilisé ou personnalisé au-delà de quelques visuels. Je ne suis au courant d’aucun paramètre qui pourrait l’empêcher d’être atteint. J’ai créé un ticket auprès de la société d’hébergement WP pour voir s’ils peuvent comprendre pourquoi les connexions échouent, car je suis plus préoccupé par leur configuration inhabituelle.

Ce qui m’intéresse, c’est que le simple fait que le forum puisse atteindre WP (pas l’inverse) est “suffisant” pour un SSO fonctionnel. Sauf pour la déconnexion des utilisateurs du forum.

Logs (le site en direct télécharge une archive ZIP de 0 octet).

8

Ouais, j’attendrais d’abord le résultat de cela, sinon nous pourrions tourner en rond ici. La question fondamentale est de savoir pourquoi une requête WP standard ne peut pas atteindre votre forum.