Stiamo gestendo una suite di servizi per una comunità chiusa specifica e stiamo valutando l’inclusione di Discourse come piattaforma sociale. Mi chiedo qual sia il modo migliore ed più elegante (a livello tecnico) per integrare in modo trasparente un’istanza di Discourse nella nostra suite.
Facciamo un esempio: la nostra suite include il servizio A e il servizio B (sviluppati internamente) nonché un servizio OAuth2 SSO.
Se un utente clicca per accedere dal servizio A o dal servizio B, viene reindirizzato al servizio SSO dove effettua il login e poi viene reindirizzato indietro come di consueto. Tuttavia, grazie a cookie e controllo delle sessioni, l’accesso al servizio A non richiederà all’utente di effettuare nuovamente il login sul servizio B se decide di visitarlo successivamente (avrà già una sessione attiva).
Allo stesso modo, vorremmo un modo per permettere agli utenti di navigare in modo trasparente verso il servizio Discourse dal servizio A o B dopo aver effettuato il login tramite il servizio SSO. Si assuma che l’utente esista già in tutti i servizi. Attualmente, il plugin OAuth2 di Discourse è stato valutato e funziona con il nostro servizio SSO, ma richiede agli utenti di cliccare nuovamente su “Accedi con SSO” quando visitano Discourse. Esiste un modo, ad esempio una chiamata API, per avviare automaticamente una sessione anche su Discourse quando gli utenti accedono tramite l’SSO comune dal servizio A o B?
Inoltre, la domanda sopra si estende anche all’integrazione dei commenti tramite il componente incorporato. Mantenere un servizio Discourse “pubblico” non pone problemi per la sezione commenti, e i commenti vengono incorporati correttamente. Tuttavia, se si esegue un servizio Discourse privato, la finestra dei commenti incorporata non visualizzerà correttamente i commenti se l’utente non ha effettuato il login anche su Discourse in precedenza, il che rappresenta un problema quando si parla di integrazione trasparente.
Esiste un modo per aggirare questi problemi? Stavo pensando di costruire un plugin middleware che decodifichi un token o un cookie e autentichi e effettui immediatamente il login per l’utente appropriato prima di effettuare la chiamata effettiva. Esiste già un plugin del genere?
Thank you for the quick reply. However, this does not solve the problem. Both on the embedded Discourse comment window as well as when going to the Discourse site, the user (who is already logged in to, say, “service A” via the SSO), will need to log in again.
In both cases I am greeted with a welcome message: “Welcome, An account is required. Please ask an existing member for an invite or log in to continue.” and the log-in button. When I click it, the log-in pops up and I am prompted to log-in via username/password or via the OAuth SSO. I am not required to enter my SSO’s username and password again because the SSO session is still active, however I don’t want users to experience that. When the user logs-in to “service A” he/she needs to automatically be logged-in to Discourse as well without having to press any “Log in” button again.
What do we need to achieve that?
I am using Discourse version 2.5.2 if that’s relevant
Nell’ultima versione di Discourse, a condizione che siano abilitate sia “login richiesto” che “autenticazione immediata”, l’utente verrà automaticamente registrato su Discourse purché abbia già un cookie valido nel Provider di Identità.
Nelle versioni precedenti all’ultima, questo flusso di “magico” accesso era limitato ai siti che utilizzano il nostro protocollo SSO, descritto in Single-Sign-On ufficiale per Discourse (sso).
Hmm, I’m using bitnami images and their latest is still 2.5.2, so I’ll probably have to wait a bit for that (or find a way to do a manual update, or use some other image).
Anyway, thank you for pointing me to the right direction. Much appreciated!
Keep in mind the bitnami images are not supported by the Discourse developers, and over the years had many incompatibilities with the normal usage of the software. I strongly suggest using an Discourse official Standard Installation