Hey,
I’ve set up discourse to use Auth0 as the SSO provider. The problem I have is that when a user registers they are recieving two verification emails. One from auth0 and one from discourse.
Is there anyway to disable the one from discourse?
Thanks in advance
If email addresses are being verified by Auth0, you can disable Discourse verification emails by selecting the oauth2 email verified site setting. There is a reference to that setting in this post: Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.
Thanks for the answer @simon but I’m using SSO not Oauth2
The term SSO gets used for a few different authentication methods. This has caused confusion a few times in the past.
If you are using the Discourse implementation of SSO, then email verification is controlled by the require_activation SSO parameter. Set that parameter to "false" to bypass email verification.
Thanks again @simon
I want to avoid disabling it completely. At the moment I have it set up so that require_activation returns true false based upon whether they have been verified by auth0. This works fine and after they have clicked on the auth0 email the next time they login they get verified on discourse.
So ideally it would just be suppressing the email unless I’m missing something
That makes sense. Our WordPress plugin handles email verification in the same way.
If you want to see how the require_activation value is used by Discourse, have a look at this file: https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. You’ll see that when require_activation is set to "false" when a user is first created via SSO, an active user will be created by Discourse. If it is set to "true", the user will not be activated until they click the link in the Discourse activation email.
Once a user is set to active on Discourse, the only thing that should cause a user to need to be reactivated is if you have enabled the sso_overrides_email site setting and the user updates their email address on your SSO provider site.
When set to "true", require_activation also prevents Discourse from matching existing users to users from your external site based on their email address. This can cause issues when SSO is implemented after users have already been created on the site with username/password account creation.
Thank you that makes sense, however I’m not sure how this stops the “verify email” email from discourse getting sent?
I just want the one from auth0 to be sent
To only have the verification email sent from your SSO provider site, users will need to register on that site and verify their email address before they first login to Discourse. You will then be able to set the require_activation parameter to "false" for those users. They will be created as active users on Discourse and not get sent the Discourse activation email.
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.