Stiamo utilizzando OAuth esterno per l’autenticazione degli utenti. Occasionalmente gli utenti ricevono l’errore 500 quando accedono alla piattaforma: Snippet dal log degli errori:
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'
Se l’utente semplicemente ricarica la pagina, tutto funziona, con le seguenti informazioni nel log:
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)
Purtroppo non ci sono passaggi per riprodurre il problema. Tende a verificarsi quando gli utenti che sono stati assenti per un periodo di tempo più lungo, ma non posso confermarlo con certezza. È possibile che ci sia stato un aggiornamento della piattaforma dalla loro ultima visita.
Avete suggerimenti o ulteriori informazioni che potrei fornire?
Pensavo anche io, ma l’errore si verifica troppo rapidamente per essere un comportamento normale. Mi chiedo se ci possa essere un timeout eccessivamente zelante per la ricerca DNS da qualche parte:
L’errore si trova in “resolver.rb”.
È temporaneamente risolto con un refresh, quando la ricerca DNS verrebbe memorizzata nella cache.
Per qualche ragione completamente inspiegabile, non riesco a leggere il documento di discovery OIDC da alcun URL che coinvolga il nostro DNS self-hosted. Questo nonostante sia perfettamente in grado di fare curl del file manualmente dall’interno dell’istanza Docker. Ho eliminato molte variabili diverse e il DNS sembra essere l’unico fattore comune.
È importante notare che il server Discourse è in grado di comunicare con il server OIDC, anche quando fallisce in questo modo. Dai log di accesso, c’è una richiesta:
quando ha successo. Indipendentemente da ciò, non ci vuole mai più di 5 secondi. Devo ancora provare a configurare un proxy per il server OIDC che utilizzi il DNS di Cloudflare, ma questo sarà il mio prossimo passo.
Beh, è sicuramente un problema di DNS. Invece di configurare un proxy, ho semplicemente aggiunto il mio server OIDC al file hosts nel container Docker e ora sembra funzionare. Questa è comunque una soluzione fragile e subottimale; penso che gli sviluppatori debbano correggere il timeout in modo che sia qualcosa di sensato. Questo caso mi ricorda la storia dell’email dei 500 miglia.
Nel mio caso, IdP e Discourse VMs si trovano una accanto all’altra e, sebbene nessuno possa escludere completamente possibili problemi di rete, nessun altro servizio li riscontra.