Ciao,
Ho configurato Discourse per utilizzare Auth0 come provider SSO. Il problema che riscontro è che, quando un utente si registra, riceve due email di verifica: una da Auth0 e una da Discourse.
È possibile disattivare quella di Discourse?
Grazie in anticipo
Se gli indirizzi email vengono verificati da Auth0, puoi disabilitare le email di verifica di Discourse selezionando l’impostazione del sito oauth2 email verified. C’è un riferimento a questa impostazione in questo post: Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.
Grazie per la risposta @simon, ma sto utilizzando SSO, non OAuth2.
Il termine SSO viene utilizzato per diversi metodi di autenticazione. Questo ha causato confusione in diverse occasioni in passato.
Se stai utilizzando l’implementazione di SSO di Discourse, la verifica dell’email è controllata dal parametro SSO require_activation. Imposta quel parametro su "false" per bypassare la verifica dell’email.
Grazie ancora @simon
Voglio evitare di disabilitarlo completamente. Al momento ho configurato il sistema in modo che require_activation restituisca true o false in base alla verifica effettuata da Auth0. Funziona bene: dopo aver cliccato sull’email di Auth0, alla prossima login l’utente viene verificato su Discourse.
Quindi, idealmente, basterebbe sopprimere l’email, a meno che non mi stia perdendo qualcosa.
Ha senso. Il nostro plugin per WordPress gestisce la verifica dell’email nello stesso modo.
Se vuoi vedere come viene utilizzato il valore require_activation da Discourse, consulta questo file: https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. Vedrai che quando require_activation è impostato su "false" al momento della creazione di un utente tramite SSO, Discourse crea un utente attivo. Se è impostato su "true", l’utente non verrà attivato fino a quando non cliccherà sul link contenuto nell’email di attivazione di Discourse.
Una volta che un utente è impostato come active su Discourse, l’unica cosa che potrebbe richiedere una riattivazione è se hai abilitato l’impostazione del sito sso_overrides_email e l’utente aggiorna il proprio indirizzo email sul sito del provider SSO.
Quando è impostato su "true", require_activation impedisce anche a Discourse di abbinare gli utenti esistenti a quelli del tuo sito esterno in base all’indirizzo email. Questo può causare problemi quando l’SSO viene implementato dopo che gli utenti sono già stati creati sul sito tramite account con nome utente e password.
Grazie, ha senso, però non sono sicuro di come questo impedisca l’invio dell’email di “verifica email” da Discourse.
Vorrei che venisse inviata solo quella di Auth0.
Per far sì che l’email di verifica venga inviata solo dal sito del provider SSO, gli utenti dovranno registrarsi su quel sito e verificare il proprio indirizzo email prima di accedere per la prima volta a Discourse. Potrai quindi impostare il parametro require_activation su "false" per tali utenti. Verranno creati come utenti attivi su Discourse e non riceveranno l’email di attivazione di Discourse.
Questo non ha senso. Come posso far sì che verifichino l’email prima del primo accesso a Discourse?
Il mio sito si occupa già della verifica delle email: come posso disattivare l’invio dell’email di verifica da parte di Discourse, ma continuare a mostrare all’utente un messaggio che richiede l’autenticazione?
DiscourseConnect presuppone che tu stia validando gli indirizzi email sul tuo sito. Finché lo fai, non impostare il parametro require_activation nel payload SSO. Se quel parametro non è presente nel payload, gli utenti accederanno a Discourse senza che venga inviata loro un’email di attivazione.
Sì, ma in tal caso Discourse assumerà che siano stati validati, il che potrebbe non essere vero se l’utente ha visitato il forum e ha dimenticato o deciso di non validare l’email. Se il sito web imposta require_validation su true, significa che l’utente non ha ancora validato la propria email sul sito, ma ha sicuramente ricevuto un link di validazione, quindi non c’è bisogno che Discourse lo invii di nuovo. Tuttavia, lo farà a causa di questo parametro.
In pratica, il problema si presenta solo se l’utente accede a Discourse prima della validazione. Quindi, al momento, devo essenzialmente scegliere tra due opzioni:
Esiste una terza opzione: aggiungere un interruttore che funzioni solo se SSO è abilitato, disabilitando l’email di verifica da Discourse (ma lasciando una pagina di errore che informa l’utente che non è stato verificato).
Idealmente, quando un utente crea un account sul tuo sito web, dovrai validare il suo indirizzo email facendogli rispondere a un’email di attivazione inviata dal tuo sito web al momento della registrazione. Se, per qualche motivo, consenti agli utenti di creare account sul tuo sito web prima di aver validato il loro indirizzo email, puoi impostare il parametro require_validation in modo condizionale nel payload SSO. Se l’utente ha già validato il proprio indirizzo email, imposta require_validation su false o semplicemente ometti il parametro dal payload. Se l’utente non ha validato il proprio indirizzo email sul tuo sito web, imposta il parametro require_activation su true in modo che gli venga inviata un’email di attivazione da Discourse.
È esattamente quello che sto facendo ed è un problema. Ad esempio, un utente si registra, riceve un’email di attivazione dal sito web, ma invece di aprirla e attivare l’account, decide di andare su Discourse, perché no. A quel punto, require_activation verrà impostato su true, perché l’utente non è ancora stato attivato. Tuttavia, Discourse deciderà che l’utente ha bisogno di un’altra email di attivazione, il che è un problema, dato che c’è già un’email di attivazione dal sito web in attesa di essere aperta. Discourse dovrebbe semplicemente visualizzare un messaggio di errore in cui si dice all’utente di controllare la propria casella di posta.