Nous utilisons l’authentification OAuth externe pour les utilisateurs. Parfois, les utilisateurs reçoivent une erreur 500 lorsqu’ils accèdent à la plateforme : Extrait du journal d’erreurs :
Started GET "/auth/oauth2_basic/callback?code=[coderemoved]&state=[stateremoved]" for [IP] at [timestamp]
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Callback phase initiated.
Faraday::TimeoutError (Timeout::Error)
lib/final_destination/resolver.rb:31:in `block in lookup'
lib/final_destination/resolver.rb:8:in `synchronize'
lib/final_destination/resolver.rb:8:in `lookup'
lib/final_destination/ssrf_detector.rb:127:in `lookup_ips'
lib/final_destination/ssrf_detector.rb:95:in `lookup_and_filter_ips'
lib/final_destination/http.rb:13:in `connect'
lib/middleware/omniauth_bypass_middleware.rb:43:in `call'
lib/middleware/content_security_policy.rb:12:in `call'
lib/middleware/anonymous_cache.rb:387:in `call'
lib/middleware/gtm_script_nonce_injector.rb:10:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:233:in `call'
Si l’utilisateur recharge simplement la page, tout fonctionne, avec les informations de journalisation suivantes :
Started GET "/auth/oauth2_basic/callback?code=[coderemoved]&state=[stateremoved]" for [IP] at [timestamp]
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Callback phase initiated.
Processing by Users::OmniauthCallbacksController#complete as HTML
Parameters: {"code"=>"[coderemoved]", "state"=>"[stateremoved]", "provider"=>"oauth2_basic"}
Deprecation notice: `SiteSetting.anonymous_posting_min_trust_level` has been deprecated. Please use `SiteSetting.anonymous_posting_allowed_groups` instead. (removal in Discourse 3.3)
At /var/www/discourse/lib/site_setting_extension.rb:160:in `public_send`
start
Redirected to https://[pageremoved]
Completed 302 Found in 83ms (ActiveRecord: 0.0ms | Allocations: 11138)
Malheureusement, aucune étape pour reproduire le problème. Il a tendance à se produire lorsque les utilisateurs qui ont été absents pendant une période plus longue, mais je ne peux pas le confirmer avec certitude. Il est possible qu’une mise à niveau de la plateforme ait eu lieu depuis leur dernière visite.
Avez-vous des suggestions ou des informations supplémentaires que je pourrais fournir ?
Je pensais à ça, mais l’erreur survient beaucoup trop rapidement pour que ce soit un comportement normal. Je me demande s’il n’y a pas un délai d’attente trop zélé pour la résolution DNS quelque part :
L’erreur se trouve dans “resolver.rb”.
Elle est temporairement corrigée par un rafraîchissement - lorsque la résolution DNS serait mise en cache.
Pour une raison tout à fait inexplicable, je n’arrive pas à lire le document de découverte OIDC depuis une URL impliquant notre DNS auto-hébergé. Et ce, malgré le fait que je puisse parfaitement curl le fichier manuellement depuis l’instance Docker. J’ai éliminé de nombreuses variables différentes et le DNS semble être le seul facteur commun.
Il est important de noter que le serveur Discourse peut communiquer avec le serveur OIDC, même lorsqu’il échoue comme ceci. D’après les journaux d’accès, il y a une requête :
lorsque cela réussit. Quoi qu’il en soit, cela ne prend jamais plus de 5 secondes. Je n’ai pas encore essayé de configurer un proxy pour le serveur OIDC qui utilise le DNS de Cloudflare, mais ce sera ma prochaine étape.
Eh bien, c’est définitivement un problème de DNS. Plutôt que de configurer un proxy, j’ai simplement ajouté mon serveur OIDC au fichier hosts dans le conteneur Docker et cela semble fonctionner maintenant. C’est cependant une solution fragile et sous-optimale ; je pense que les développeurs doivent corriger le délai d’attente pour qu’il soit raisonnable. Ce cas me rappelle l’histoire de l’e-mail des 500 miles.
Vous pouvez ajouter des éléments à votre fichier app.yml pour mettre à jour /etc/hosts lors d’une reconstruction. Vous pouvez consulter d’autres modèles pour des exemples.
C’est possible, mais peu de gens ont des problèmes. Votre serveur DNS auto-hébergé pourrait-il être surchargé parfois ?
Je ne sais pas où changer le délai d’attente. Je ne me souviens pas l’avoir jamais fait.
Dans mon cas, les machines virtuelles IdP et Discourse sont côte à côte et, bien que personne ne puisse exclure totalement d’éventuels problèmes réseau, aucun autre service n’en rencontre.