Salut,
J’ai configuré Discourse pour utiliser Auth0 comme fournisseur SSO. Le problème que je rencontre est qu’un utilisateur qui s’inscrit reçoit deux e-mails de vérification : un d’Auth0 et un de Discourse.
Existe-t-il un moyen de désactiver celui envoyé par Discourse ?
Merci d’avance.
Si les adresses e-mail sont vérifiées par Auth0, vous pouvez désactiver les e-mails de vérification de Discourse en sélectionnant le paramètre du site oauth2 email verified. Une référence à ce paramètre se trouve dans ce message : Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.
Merci pour la réponse @simon, mais j’utilise SSO et non OAuth2
Le terme SSO est utilisé pour plusieurs méthodes d’authentification différentes. Cela a déjà causé de la confusion à plusieurs reprises par le passé.
Si vous utilisez l’implémentation SSO de Discourse, la vérification par e-mail est contrôlée par le paramètre SSO require_activation. Définissez ce paramètre sur "false" pour contourner la vérification par e-mail.
Merci encore @simon
Je souhaite éviter de le désactiver complètement. Pour l’instant, j’ai configuré require_activation pour qu’il renvoie true ou false selon que l’utilisateur a été vérifié par Auth0. Cela fonctionne bien : après avoir cliqué sur le lien de vérification dans l’email d’Auth0, l’utilisateur est automatiquement marqué comme vérifié sur Discourse lors de sa prochaine connexion.
Idéalement, il suffirait donc de supprimer simplement l’envoi de l’email, sauf si j’oublie quelque chose.
Cela a du sens. Notre plugin WordPress gère la vérification par e-mail de la même manière.
Si vous souhaitez voir comment la valeur require_activation est utilisée par Discourse, consultez ce fichier : https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. Vous verrez que lorsque require_activation est défini sur "false" lors de la création initiale d’un utilisateur via SSO, Discourse crée un utilisateur actif. S’il est défini sur "true", l’utilisateur ne sera activé qu’après avoir cliqué sur le lien contenu dans l’e-mail d’activation de Discourse.
Une fois qu’un utilisateur est défini comme active sur Discourse, la seule chose qui devrait obliger à le réactiver est si vous avez activé le paramètre du site sso_overrides_email et que l’utilisateur met à jour son adresse e-mail sur votre site fournisseur SSO.
Lorsqu’il est défini sur "true", require_activation empêche également Discourse d’associer les utilisateurs existants à ceux de votre site externe en fonction de leur adresse e-mail. Cela peut poser problème lorsque le SSO est mis en œuvre après que des utilisateurs ont déjà été créés sur le site avec un compte username/mot de passe.
Merci, cela a du sens. Cependant, je ne suis pas sûr de la manière dont cela empêche l’envoi de l’e-mail de « vérifier l’e-mail » provenant de Discourse.
Je veux simplement que celui d’Auth0 soit envoyé.
Pour que l’e-mail de vérification soit envoyé uniquement depuis le site de votre fournisseur SSO, les utilisateurs devront s’inscrire sur ce site et vérifier leur adresse e-mail avant de se connecter pour la première fois à Discourse. Vous pourrez alors définir le paramètre require_activation sur "false" pour ces utilisateurs. Ils seront créés comme utilisateurs actifs sur Discourse et ne recevront pas l’e-mail d’activation de Discourse.
Cela n’a pas de sens. Comment puis-je obliger les utilisateurs à vérifier leur adresse e-mail avant leur première connexion à Discourse ?
Mon site gère déjà la vérification des e-mails. Comment puis-je désactiver l’envoi d’e-mails de vérification par Discourse tout en affichant aux utilisateurs un message leur indiquant qu’ils doivent s’authentifier ?
DiscourseConnect suppose que vous validez les adresses e-mail sur votre site web. Tant que vous le faites, ne définissez pas le paramètre require_activation dans la charge utile SSO. Si ce paramètre n’est pas présent dans la charge utile, les utilisateurs seront connectés à Discourse sans qu’un e-mail d’activation ne leur soit envoyé.
Oui, mais alors Discourse supposera qu’ils sont validés, ce qui pourrait ne pas être vrai si l’utilisateur a accédé au forum et a oublié ou décidé de ne pas valider son adresse e-mail. Si le site web définit require_validation à true, cela signifie que l’utilisateur n’a pas encore validé son e-mail sur le site, mais a bien reçu un lien de validation ; il n’est donc pas nécessaire que Discourse l’envoie à nouveau, mais il le fera à cause de ce paramètre.
Le problème ne se pose essentiellement que si l’utilisateur accède à Discourse avant la validation. Pour l’instant, je dois essentiellement choisir entre deux options :
Il existe une troisième option : ajouter un commutateur qui ne fonctionne que si SSO est activé, désactivant l’e-mail de vérification de Discourse (tout en laissant une page d’erreur indiquant à l’utilisateur qu’il n’est pas vérifié).
Idéalement, lorsqu’un utilisateur crée un compte sur votre site web, vous devez valider son adresse e-mail en lui demandant de répondre à un e-mail d’activation envoyé depuis votre site web lors de son inscription. Si, pour une raison quelconque, vous autorisez les utilisateurs à créer des comptes sur votre site web avant qu’ils n’aient validé leur adresse e-mail, vous pouvez définir le paramètre require_validation de manière conditionnelle dans la charge utile SSO. Si l’utilisateur a validé son adresse e-mail, définissez require_validation sur false, ou omittez simplement ce paramètre de la charge utile. Si l’utilisateur n’a pas validé son adresse e-mail sur votre site web, définissez le paramètre require_activation sur true afin qu’un e-mail d’activation lui soit envoyé par Discourse.
C’est exactement ce que je fais, et c’est un problème. Par exemple, un utilisateur s’inscrit et reçoit un e-mail d’activation depuis le site web, mais au lieu de l’ouvrir et de l’activer, il décide d’aller sur Discourse, pourquoi pas. Ensuite, require_activation sera défini sur true, car l’utilisateur n’a pas encore été activé. Mais Discourse décidera que l’utilisateur a besoin d’un autre e-mail d’activation, ce qui pose problème, car un e-mail d’activation du site web est déjà en attente d’ouverture. Discourse devrait simplement afficher un message d’erreur indiquant que l’utilisateur doit vérifier ses e-mails.