Conexión fallida de DC SSO ralentiza al administrador con un tiempo de espera

He configurado Discourse Connect SSO usando el plugin oficial, por lo que mis usuarios de WP inician sesión en Discourse sin registrar otro usuario allí. Todo funciona bien, excepto que cada solicitud del panel de control de WP (área de administración) se ralentiza en 10 segundos debido a un tiempo de espera que descubrí solo a través del plugin Query Monitor.

https://{nuestra-dirección-del-foro}/site.json cURL error 28: Connection timeout after 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

Incluso si funcionara, ¿por qué hay una necesidad de una llamada como esta en primer lugar? ¿Cómo puedo deshabilitarla?

El foro y el sitio están en servidores separados. No hay Cloudflare. SSL es letsencrypt. No tuvo este problema en staging. Me mudé a producción, creé una nueva clave API y secreto, intenté resolver esto pero no funcionó.

El plugin dice No estás conectado a Discourse. Comprueba que la configuración de tu conexión sea correcta. Si el problema persiste, habilita los registros de conexión y consulta los Registros. …pero sí lo estoy, ya que los usuarios pueden iniciar sesión sin problemas en el foro simplemente haciendo clic en un enlace que contiene su dirección.

Los registros en WP dicen:


[2024-10-31 10:54:47] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Se devolvió una respuesta no válida desde Discourse","http_code":"","http_body":""}

Pensé que esa extraña cosa de seguridad de WP la estaba paralizando, así que agregué esto pero tampoco funcionó:


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 === "{nuestra-dirección-del-foro}") {
        return true; // Permitir la solicitud indicando que el host SÍ es externo
    }

    return $is_external;
}

Hola @Firsh,

Esa llamada a tu /site.json es necesaria para que el plugin de Wordpress recupere información sobre tu Discourse.

Eso significa que no estás conectado correctamente, y aunque las cosas parezcan funcionar, no contaría con que sigan funcionando.

Esto es en lo que necesitamos centrarnos. ¿Podrías compartir qué tipo de clave creaste? Como referencia, asegúrate de seguir las directrices sobre esto aquí:

2 Me gusta

No creo que sea la clave. Lo intenté con la clave del sitio de staging de antemano, y la nueva dice “nunca usada”. Cuando intento una llamada de prueba wp_remote_request a la página de inicio de mi foro, también se agota el tiempo de espera. Lo configuré para “cada usuario” y “global”.

Sí, pero ¿por qué todo el tiempo en cada página de administración no relacionada? Una vez cuando sea necesario sería suficiente. Descubrí de dónde viene y es function get_discourse_categories() y esto está codificado en add_action( 'admin_init', array( $this, 'setup_options' ) ); No quiero que mi WP sepa sobre las categorías en el foro, no estoy usando ninguna función de publicación/comentario, solo necesito el inicio de sesión, que ya funciona.

También hice una solicitud a la página de inicio del foro usando wp_remote_request() y eso también se agota el tiempo de espera. Otros sitios aleatorios son accesibles.

Entiendo que sientes que la solicitud a /site.json es innecesaria, sin embargo, sin una conexión exitosa a tu Discourse, el plugin de Wordpress no funcionará de manera confiable para ti, así que deberíamos averiguar por qué eso no está funcionando de todos modos.

  1. ¿Se te ocurre alguna otra diferencia entre tu entorno de staging y producción?
  2. ¿Podrías compartir los archivos meta del registro de WP Discourse de tus instancias de staging y producción?
  3. ¿Podrías compartir enlaces a tus instancias de Wordpress y Discourse?
1 me gusta

Sí, pero es un sitio y foro privado solo para miembros en húngaro.

Foro: https://forum.intelligensbefektetok.hu/
Sitio: https://intelligensbefektetok.hu/

Mi staging era una copia exacta hecha manualmente, aunque ejecutándose en Docker en una VM. La producción no está gestionada por mí, y no tengo idea de qué tipo de hosting es, pero nunca tuvimos ningún problema y era bastante rápido antes de esto.

Lo intenté ahora:

  • La opción sslverify = false en la función discourse_request
  • Y creé un CNAME (alias) en Cloudflare en otro de mis dominios para que apunte al host del foro entre bastidores (“mejor” SSL y el host es diferente, para descartar algún tipo de restricción de loopback en el firewall del host del sitio en vivo): https://ibkforum.stateofbliss.us pero se agota el tiempo de espera de la misma manera, mientras que las pruebas de solicitudes desde staging funcionan bien. Redirige al sitio principal cuando no se ha iniciado sesión.
  • Estoy usando este pequeño plugin para verificar las solicitudes: 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) { } }

  • Otros sitios de WP; este foro; el sitio en vivo al hacer una solicitud a sí mismo, todo funciona bien.

Registro de WP de staging:

[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

Los registros del sitio en vivo son los mismos que en mi OP:

[2024-10-31 13:12:32] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Se devolvió una respuesta no válida de Discourse","http_code":"","http_body":""}

Cuando se carga directamente en el navegador, esto funciona:
https://forum.intelligensbefektetok.hu/site.json

Gracias por tu ayuda, por cierto.

¿Te refieres a la producción de Wordpress o a la producción de Discourse? ¿Es posible que haya algo en tu entorno de producción de Discourse que esté realizando redirecciones y/o cambiando (o eliminando) encabezados en las solicitudes?

Si pudieras compartir esos archivos meta de ambas instancias, eso ayudaría. Haz clic en “Ver Meta” en el panel de administración de “Registros”.

Este es probablemente el problema fundamental. Si tu Wordpress no puede ver tu Discourse en absoluto, la conexión no funcionará. Si puedes probar fácilmente esta conectividad, sigue haciéndolo mientras realizas cualquier ajuste en la capa de red de tu foro hasta que obtengas un 403 (es decir, no autorizado).

Mi instinto me dice que este es un problema de la capa de red, quizás una redirección o un firewall.

No hay un Discourse de staging, ambos sitios usan el mismo Discourse en vivo (mismos IDs de usuario, etc.). Pregunté sobre esto en otro hilo y debería estar bien. La capa de red del foro es muy simple, alojada en Hetzner, la cosa oficial de Docker en un VPS, y el foro apenas se ha utilizado o personalizado más allá de algunos aspectos visuales. No conozco ninguna configuración que impida que se pueda acceder a él. Creé un ticket en la empresa de alojamiento de WP para ver si pueden ver por qué fallan las conexiones, ya que me preocupa más su configuración inusual.

Lo interesante para mí es que el mero hecho de que el foro pueda llegar a WP (no al revés) es “suficiente” para un SSO que funcione. Excepto por el cierre de sesión de los usuarios del foro.

Logs (el sitio en vivo descarga un ZIP de 0 bytes).

Sí, esperaría el resultado de esto primero, de lo contrario podríamos estar perdiendo el tiempo aquí. La pregunta básica es por qué una solicitud estándar de WP no puede llegar a tu foro.