Fiducia: Discourse come provider OpenID Connect

Se volevi sempre usare Discourse come provider di autenticazione, ora puoi!

Nell’ultima settimana ho scritto un piccolo servizio che può fungere da provider OpenID Connect/OAuth con Discourse come backend.

Puoi consultare il codice qui:

Tieni presente che il mio caso d’uso principale era l’autenticazione su Nextcloud tramite Discourse, quindi potrebbe non funzionare per il tuo caso specifico.

Se qualcosa non funziona come previsto o manca quella determinata funzionalità per farlo funzionare per te, sentiti libero di aprire un issue nel repository GitHub.

18 Mi Piace

Iniziativa fantastica! Ho sempre voluto che Discourse fosse utilizzabile come provider OAuth, in modo da poter essere integrato facilmente con più strumenti. Renderlo un servizio esterno di piccole dimensioni ha molto senso anche!

6 Mi Piace

Mi piace come suona e spero che alcune comunità decidano di provarlo!

Mi piacerebbe vedere OIDC supportato ufficialmente da Discourse, oltre alla nostra funzionalità personalizzata Discourse Connect, in modo da poter offrire una soluzione pronta all’uso ai nostri clienti sui piani Standard e Teams, senza dover fare affidamento su Okta o simili.

7 Mi Piace

È super figo! Grazie per averlo fatto!

Mi piacerebbe davvero vederlo integrato in Discourse in modo che possa diventare un proprio provider OIDC!

5 Mi Piace

Fantastico, adoro che permetta l’accesso per gruppo.

1 Mi Piace

@theSuess Sto usando Discourse come applicazione standalone, quindi come posso configurarlo?



Distrust è un servizio separato, quindi devi distribuirlo come tale. Puoi eseguirlo in un contenitore come descritto nel file README. Tieni presente che, per un’operazione sicura, avrai anche bisogno di un reverse proxy che gestisca la terminazione SSL (potrei implementarlo direttamente in un futuro).

2 Mi Piace

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!