Fiducia: Discourse come provider OpenID Connect

Plugin Extra
12

Spero di ricevere un parere esperto sui problemi che sto riscontrando nell’utilizzo di Discourse come provider SSO.

Il mio obiettivo: Sto configurando Discourse per gestire l’autenticazione per un’altra applicazione (LibreChat). Sto utilizzando la funzionalità standard del provider DiscourseConnect, con il servizio bridge OIDC distrust che funge da client che comunica con Discourse.

Il problema: Il flusso SSO funziona perfettamente fino all’ultimo passaggio. L’utente viene reindirizzato correttamente dalla mia app a Discourse e può accedere con successo utilizzando le proprie credenziali Discourse. Tuttavia, dopo l’accesso, viene reindirizzato alla homepage del mio forum Discourse (/) invece che all’return_sso_url che era stato fornito.

Dove sono bloccato (Cosa ho escluso): Ho cercato di risolvere questo problema per un po’ e ho confermato che non si tratta di un semplice errore di configurazione. Ho definitivamente escluso quanto segue:

  • Segreti: I segreti del provider Discourse Connect sono configurati correttamente. Sto utilizzando il dominio semplice (ad esempio, auth.my-site.com) senza alcun protocollo e la chiave segreta corrisponde perfettamente a quella nel mio servizio client.
  • Modalità SSO: Ho verificato che abilita provider Discourse Connect sia selezionato e che le impostazioni errate di “Client SSO” siano disabilitate.
  • Criteri utente: Mi sono assicurato che must_approve_users sia disabilitato e che il mio utente di test sia un amministratore con un’e-mail completamente verificata.
  • Plugin: Ho disabilitato tutti i plugin di terze parti non ufficiali e ricostruito il container, ma il problema persiste.

Le prove chiave: Ho due prove definitive che mi lasciano perplesso:

  1. Analisi del file HAR: Ho catturato l’intero flusso di rete in un file HAR. Mostra che la richiesta POST a /session per l’accesso ha successo. Il server risponde immediatamente con un reindirizzamento 302 Found, ma l’intestazione Location è costantemente /. Ciò dimostra che Discourse sta intenzionalmente interrompendo il reindirizzamento SSO.
  2. Log Rails vuoto: Ho quindi monitorato il file production.log all’interno del container durante il tentativo di accesso. Non viene scritto assolutamente nulla nel log durante questo processo. Ciò mi dice che Discourse non lo considera un errore; è un’azione deliberata e silenziosa.

La mia domanda: Dato che l’accesso ha successo, ma il reindirizzamento è errato e non ci sono errori nei log, quale criterio interno di Discourse, controllo preliminare o impostazione nascosta potrebbe causare l’ignoranza dell’return_sso_url e il reindirizzamento alla homepage? Sento di aver esaurito tutte le impostazioni standard.

Grazie in anticipo per qualsiasi idea!