Conexão DC SSO com falha está atrasando a administração devido a um timeout

Suporte WordPress
1

Configurei o Discourse Connect SSO usando o plugin oficial, para que meus usuários do WP façam login no Discourse sem registrar outro usuário lá. Tudo funciona bem, exceto que cada solicitação do painel do WP (área administrativa) é atrasada em 10s devido a um timeout que descobri apenas através do plugin Query Monitor.

https://{nosso-endereço-do-fórum}/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

Mesmo que funcionasse, por que há necessidade de uma chamada como essa em primeiro lugar? Como posso desativá-la?

Fórum e site estão em servidores separados. Não há Cloudflare. SSL é letsencrypt. Não teve esse problema no staging. Mudei para o live, criei uma nova chave de API e segredo, tentando resolver isso, mas não funcionou.

O plugin diz Você não está conectado ao Discourse. Verifique se as configurações de conexão estão corretas. Se o problema persistir, ative os logs de conexão e verifique os Logs. …mas estou, pois os usuários conseguem fazer login no fórum sem problemas apenas clicando em um link que contém seu endereço.

Os logs no WP dizem:


[2024-10-31 10:54:47] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Uma resposta inválida foi retornada do Discourse","http_code":"","http_body":""}

Pensei que essa coisa estranha de segurança do WP a estivesse prejudicando, então adicionei isso, mas também não adiantou:


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 === "{nosso-endereço-do-fórum}") {
return true; // Permite a solicitação indicando que o host É externo
}

return $is_external;
}
2

Olá @Firsh,

Essa chamada para o seu /site.json é necessária para que o plugin do WordPress recupere informações sobre o seu Discourse.

Isso significa que você não está conectado corretamente e, mesmo que as coisas pareçam estar funcionando, eu não contaria com elas para continuar funcionando.

É nisso que precisamos focar. Você poderia compartilhar que tipo de chave você criou? Como referência, por favor, certifique-se de seguir as diretrizes sobre isso aqui:

2 curtidas
3

Eu não acho que seja a chave. Eu tentei com a chave do site de staging antes, e a nova diz “nunca usada”. Quando eu tento uma chamada de teste wp_remote_request para a página inicial do meu fórum, isso também expira. Eu configurei para “todo usuário” e “global”.

Sim, mas por que o tempo todo em todas as páginas de administração não relacionadas? Uma vez quando necessário seria o suficiente. Eu rastreei de onde vem e é function get_discourse_categories() e isso está codificado em add_action( 'admin_init', array( $this, 'setup_options' ) ); Eu não quero que meu WP saiba sobre categorias no fórum, eu não estou usando nenhum recurso de publicação/comentário, eu só preciso do login, que já funciona.

Eu também fiz uma solicitação para a página inicial do fórum usando wp_remote_request() e isso também expira. Outros sites aleatórios são acessíveis.

4

Entendo que você acha que a solicitação para /site.json é desnecessária, no entanto, sem uma conexão bem-sucedida com o seu Discourse, o plugin do WordPress não funcionará de forma confiável para você, então devemos descobrir por que isso não está funcionando, independentemente.\n\n1. Você consegue pensar em alguma outra diferença entre seu ambiente de staging e produção?\n2. Você poderia compartilhar os arquivos meta de log do WP Discourse de suas instâncias de staging e produção?\n3. Você poderia compartilhar links para suas instâncias do WordPress e Discourse?

1 curtida
5

Sim, mas é um site e fórum privado apenas para membros em húngaro.

Fórum: https://forum.intelligensbefektetok.hu/
Site: https://intelligensbefektetok.hu/

Minha staging era uma cópia exata feita manualmente, embora rodando em Docker em uma VM. A produção não é gerenciada por mim, e não tenho ideia de que tipo de hospedagem é, mas nunca tivemos problemas e era bastante rápido antes disso.

Tentei agora:

  • A opção sslverify = false na função discourse_request
  • E criei um CNAME (alias) no Cloudflare em outro dos meus domínios para apontar para o host do fórum nos bastidores (“melhor” SSL e o host é diferente, para descartar algum tipo de restrição de loopback no firewall do host do site ao vivo): https://ibkforum.stateofbliss.us, mas ele expira da mesma forma, enquanto os testes de requisições da staging funcionam bem. Ele redireciona para o site principal quando não logado.
  • Estou usando este pequeno plugin para verificar as requisições: 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) { } }

  • Outros sites WP; este fórum; o site ao vivo ao fazer uma requisição para si mesmo, tudo funciona bem.

Log do WP da 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

Logs do site ao vivo são os mesmos do meu 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":""}

Quando carregado diretamente no navegador, isso funciona:
https://forum.intelligensbefektetok.hu/site.json

Obrigado pela ajuda, aliás.

6

Você quer dizer produção do Wordpress ou produção do Discourse? É possível que haja algo em seu ambiente de produção do Discourse que esteja realizando redirecionamentos e/ou alterando (ou removendo) cabeçalhos nas requisições?

Se você pudesse compartilhar esses arquivos meta de ambas as instâncias, isso ajudaria. Clique em “Ver Meta” no painel de administração “Logs”.

Este é provavelmente o problema fundamental. Se o seu Wordpress não consegue ver o seu Discourse, a conexão não funcionará. Se você conseguir testar facilmente essa conectividade, continue fazendo isso enquanto faz quaisquer ajustes na camada de rede do seu fórum até obter um 403 (ou seja, não autorizado).

Minha intuição diz que este é um problema na camada de rede, talvez um redirecionamento ou firewall.

7

Não há um Discourse de staging, ambos os sites usam o mesmo Discourse ao vivo (mesmos IDs de usuário, etc.). Perguntei sobre isso em outro tópico e não deve haver problema. A camada de rede do fórum é muito simples, hospedada na Hetzner, a coisa oficial do Docker em um VPS, e o fórum mal foi usado ou personalizado além de alguns visuais. Não estou ciente de nenhuma configuração que o impeça de ser alcançado. Criei um ticket na empresa de hospedagem do WP para ver se eles conseguem entender por que as conexões falham, pois estou mais preocupado com a configuração incomum deles.

O que me interessa é que o simples fato de o fórum poder alcançar o WP (não o contrário) é “suficiente” para um SSO funcional. Exceto pelo logout dos usuários do fórum.

Logs (o site ao vivo baixa um ZIP de 0 byte).

8

Sim, eu esperaria o resultado disso primeiro, caso contrário, podemos estar perdendo tempo aqui. A questão básica é por que uma solicitação padrão do WP não consegue alcançar seu fórum.