J’ai vu quelques sujets aborder ce problème, mais rien ne semble vraiment le traiter.
En gros, notre entreprise a été rachetée. Cela signifie que tous les utilisateurs passent de @old_company.com à @new_company.com.
J’ai une correspondance entre les anciennes et les nouvelles adresses e-mail. Ce que j’aimerais faire, c’est ajouter l’adresse e-mail @new_company.com pour un utilisateur et la confirmer automatiquement. Sinon, ils devront passer par les e-mails de confirmation eux-mêmes, ce qui, en réalité, n’arrivera pas.
Y a-t-il un moyen d’ajouter un e-mail secondaire en tant qu’administrateur et de le confirmer automatiquement ?
Simon mentionne ce qui suit :
Mais il n’est pas clair pour moi comment cela fonctionne. Comment peut-il synchroniser une adresse e-mail avec un compte, si l’adresse n’est pas encore confirmée ? Cela signifie-t-il que je devrais/pourrais :
ajouter un e-mail secondaire pour l’utilisateur via l’API
(peut-être) désactiver l’envoi d’e-mails sortants pendant 10 minutes afin qu’aucun e-mail de confirmation ne soit envoyé
activer la synchronisation des e-mails SAML
les comptes utilisateurs se confirment et se mettent à jour lorsqu’ils se connectent avec SAML
Remarque : nous changeons également de fournisseur SAML dans cet exemple
Même si l’e-mail secondaire n’a pas été confirmé, la configuration ci-dessus signifie-t-elle que lorsqu’ils essaieront de se connecter avec cet e-mail pour la première fois, il sera automatiquement confirmé et lié au compte ?
Juste pour information, un point que j’ai mal compris était l’e-mail de confirmation. En tant qu’administrateur, vous recevez deux e-mails, un pour confirmer votre ancien e-mail, puis un second pour confirmer le changement.
Je pensais que cela s’appliquait à tous les utilisateurs, mais avec le paramètre de l’image ci-dessus, vous pouvez le définir pour qu’il ne s’applique qu’au personnel. Cela signifie que les utilisateurs ne recevraient qu’un seul e-mail pour confirmer le changement.
Il faut encore trouver comment confirmer automatiquement l’e-mail pour l’utilisateur
Je ne suis pas sûr qu’il existe un moyen de confirmer automatiquement via l’interface utilisateur/l’API. Je pense que s’il y a SSO, la confirmation par e-mail/identité est gérée par eux ? Auquel cas, l’utilisation de sso_sync importerait les données/e-mails déjà confirmés et les utiliserait comme « dignes de confiance ».
Un peu de vérification des faits plus tard…
/admin/users/sync_sso est uniquement pour DiscourseConnect. Je pense que vous le saviez déjà, mais je le dis à voix haute pour quiconque lira ceci plus tard.
Mais il y a aussi le paramètre d’administration auth_overrides_emails qui pourrait être utile pour cela.
Essentiellement, si votre fournisseur SAML envoie un e-mail vérifié et que auth_overrides_emails est défini, Discourse commencera à utiliser le nouvel e-mail sans aucune confirmation envoyée par e-mail.
Ce n’est pas une réponse directe à votre question, mais : Dans le cas d’un renommage en masse d’adresses e-mail, vous pourriez le faire via la console Rails :
o = "@old_company.com"
n = "@new_company.com"
UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
ue.email.sub!(o, n)
ue.save!
end
Si vous préférez ajouter une adresse e-mail secondaire :
o = "@old_company.com"
n = "@new_company.com"
UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
sm = UserEmail.new
sm.user_id = ue.id
sm.email = ue.email.sub!(o, n)
sm.save!
end
J’ai oublié de définir saml sync sur true, mais je ne pense pas que cela aurait affecté le résultat. Le problème semble toujours être un conflit en termes de confirmation d’e-mail.
3. Résultat
Le résultat a été la création d’un nouveau compte utilisateur basé sur le nouvel e-mail de l’entreprise. Au pire, je pourrais les fusionner, mais c’est un pire cas vraiment désagréable.
Je peux toujours voir l’e-mail non confirmé dans l’ancien compte. J’essaie de renvoyer la confirmation juste pour voir ce qui se passerait, mais j’obtiens une erreur 403 (Interdit).
Il semble que l’e-mail doive être confirmé d’abord avant que nous puissions les synchroniser
À moins que je ne manque quelque chose, il semble que j’ai besoin d’un moyen de confirmer le deuxième e-mail.
Je me demande si cela pose toujours le même problème en termes de confirmation, ou s’ils sont supposés être confirmés ? Une complexité supplémentaire est que la partie utilisateur de user@company.com a également changé. Mais je soupçonne que cela signifierait que nous parcourons un CSV des correspondances entre les anciens et les nouveaux e-mails.
Je pense que cela pourrait le faire, en validant un compte SAML en fonction de l’adresse e-mail et du serveur SAML utilisés pour se connecter. Le problème est qu’il s’agit d’un fournisseur d’identité SAML (IDP) complètement différent (New Company).
Par conséquent, il remplace/crée correctement l’e-mail pour qu’il soit l’e-mail SAML, mais il le fait pour un tout nouveau compte car le compte Discourse n’est pas associé à la nouvelle adresse e-mail.
Cependant, si le compte existant a déjà la nouvelle adresse e-mail SAML confirmée dans Discourse, alors la connexion est fluide et cela devient leur nouvel e-mail de connexion SAML.
Hmm. Je pense que je travaillais peut-être sur l’hypothèse que le passage au nouvel IDP les aurait mappés en fonction d’un identifiant externe quelconque.
Je pense qu’il est possible d’activer/confirmer l’e-mail via la console Rails en ajoutant également les informations du jeton. Quelque chose comme :
old_domain = "<insert_here_the_old_domain>"
new_domain = "<insert_here_the_new_domain>"
users = UserEmail.where("email like '%" + old_domain + "'")
users.each do |user_email|
user = User.find_by_id(user_email.user_id)
user.email = user.email.gsub(old_domain, new_domain)
user.email_tokens.create(email: user.email)
user.activate
user.save!
puts "."
end
À ma connaissance, cela ne s’est pas produit. Pour une autre plateforme, nous avons dû obtenir nous-mêmes une liste d’e-mails et effectuer le mappage.
Il semble de plus en plus que ce soit la voie à suivre. Nous sommes hébergés par vous, donc je vais transmettre cela à notre CSM et suivre ce sujet avec tout progrès.
