Stiamo inviando un invito a Discourse ai nostri utenti non appena creano un account sulla nostra app. Abbiamo già il loro nome e i campi personalizzati necessari per la nostra community, ma l’utente deve inserirli nuovamente su Discourse.
Esiste un modo per completare questi campi come parte del loro profilo?
Credo che la soluzione migliore sia che la tua app funga da server SSO. Se non lo desideri, puoi far sì che la tua app crei l’utente tramite l’API e includa tali impostazioni. Puoi scoprire come farlo consultando Come fare reverse engineering dell’API di Discourse.
Non vogliamo creare utenti tramite API perché vogliamo che l’utente crei una password e scelga il proprio nome utente. Stavo valutando la possibilità di creare un utente in fase di stesura con tutti i dati, ma sembra che questo non sia possibile tramite API.
L’altra opzione che mi viene in mente è estendere gli inviti per consentire campi personalizzati e informazioni del profilo.
Forse un plugin che recupera i campi dalla tua app tramite una chiamata webhook/API? Potresti far sì che il plugin esegua qualcosa come get yoursite/user/<email_address> e popol i campi utente quando il record dell’utente viene aggiornato. Qualcosa del genere. L’SSO sembra comunque la soluzione migliore.
Con l’SSO, però, non avresti bisogno di invitarli. Basterà che visitino la tua istanza di Discourse e verranno automaticamente collegati se sono già loggati nella tua applicazione. Se non sono già loggati nell’app, Discourse li reindirizzerà alla tua applicazione per il login, e poi verranno automaticamente reindirizzati nuovamente su Discourse.
Il punto è che stiamo usando Discourse come provider SSO e finora ha funzionato bene per noi, ma sì, concordo che sarebbe più semplice se Discourse consumasse un provider SSO.
@blake Sto ancora pensando a come possiamo farlo, dato che stiamo utilizzando Discourse come provider SSO. Al momento non voglio migrare verso un’altra soluzione perché comporterebbe molto più lavoro. Hai altre idee? Non è un problema se dobbiamo scrivere codice personalizzato, ma vogliamo apportare il minor numero di modifiche possibile a come abbiamo configurato le cose.
Sono solo confuso dalla tua configurazione e da queste due frasi, perché in questo caso non hai un vero Single-Sign-On, ma un double-sign-on?
Se Discourse fosse il tuo SSO, i nuovi utenti della tua app dovrebbero essere reindirizzati prima a Discourse per creare un account, e poi reindirizzati nuovamente alla tua app, una volta autenticati. In questo modo tutte le informazioni sarebbero in un unico posto.
Allora, in base alla mia attuale comprensione, trasformerei la tua app in un provider SSO e farei in modo che Discourse lo utilizzi. Oppure reindirizzerei gli utenti della tua app a registrarsi prima su Discourse e poi a tornare alla tua app, dato che apparentemente non è così che è configurato attualmente?
In alternativa, se vuoi avere una configurazione a doppio accesso, una volta che si registrano sulla tua app, crea automaticamente, tramite API, il loro account su Discourse con una password casuale che non comunicherai mai all’utente, e compila automaticamente le informazioni del profilo che hanno inserito nella tua app. Quindi inviali alla pagina di reimpostazione della password su Discourse per il loro nuovo account, invece di inviare loro un invito.
Effettuiamo la registrazione tramite la nostra app, ma la nostra app non ha la gestione delle sessioni. Ci limitiamo ad addebitare l’utente e a memorizzare le sue informazioni nel nostro database.
Avremo bisogno di richiedere all’utente di creare prima un account, ed è proprio questo il passaggio che vogliamo eliminare, perché vogliamo rendere tutto il più semplice possibile.
È lo sforzo che non vogliamo intraprendere, perché aggiungere la gestione delle sessioni, il recupero della password, l’autenticazione a due fattori (2FA) e tutte le funzionalità fornite da Discourse richiederebbe molto lavoro.
Questo non è ciò che vogliamo.
Questo è ciò che ho fatto inizialmente, ma dobbiamo impostare un nome utente casuale e questo non è ciò che vogliamo. Anche se funzionerebbe, vogliamo che l’utente possa ancora personalizzare il proprio account prima di iniziare a utilizzare la community.
Ma sì, immagino che la risposta sia comunque quella di utilizzare un provider SSO esterno. Percorrerò questa strada e smetterò di pensare a come sfruttare Discourse e farlo funzionare nel modo che vogliamo.