J’aimerais que le système essaie une adresse e-mail secondaire si la première continue d’être rejetée.
Est-ce possible ? Sinon, quel est le but de l’adresse e-mail secondaire dans Discourse ?
J’aimerais que le système essaie une adresse e-mail secondaire si la première continue d’être rejetée.
Est-ce possible ? Sinon, quel est le but de l’adresse e-mail secondaire dans Discourse ?
Lorsqu’un utilisateur répond à un message Discourse par e-mail depuis l’adresse secondaire, le message est publié au lieu d’être rejeté en tant qu’utilisateur inconnu.
Voulez-vous dire que lorsqu’un forum n’utilise pas d’e-mail pour les sujets, l’e-mail secondaire est totalement inutile et ne peut pas être utilisé comme demandé par l’OP, même pas à des fins de connexion secondaire ?
Si c’est le cas, alors c’est plus ou moins juste du bruit pour les utilisateurs (oui, je sais - les secondaires sont là s’ils utilisent des options SSO comme Microsoft, Google, etc.)
La discussion initiale à ce sujet se trouve ici : Two emails for one user. Elle s’est poursuivie ici : Additional email address per user account support.
Je pense qu’elle a été principalement mise en œuvre pour gérer la publication sur Discourse par e-mail dans le cas où les utilisateurs ont plusieurs adresses e-mail à partir desquelles ils publient.
Il n’y a rien en place qui amènerait Discourse à tenter d’envoyer un e-mail à une adresse e-mail secondaire lorsque les e-mails envoyés à l’adresse e-mail principale échouent. Je vois à quel point cela pourrait être utile dans certains cas.
Techniquement, les adresses e-mail secondaires peuvent être utilisées pour trouver un utilisateur chaque fois que Discourse tente de trouver un utilisateur à partir d’une adresse e-mail avec User.find_by_email.
Les utilisateurs peuvent se connecter à Discourse en utilisant leur adresse e-mail secondaire.
Lorsqu’un fournisseur d’authentification externe est utilisé pour se connecter à Discourse, les utilisateurs peuvent être trouvés à partir de leur adresse e-mail secondaire en fonction de l’adresse e-mail fournie par le fournisseur d’authentification.
Fait intéressant, si le paramètre du site auth overrides email est activé et que le fournisseur d’authentification externe du site fournit l’adresse e-mail secondaire de l’utilisateur, l’adresse e-mail secondaire devient l’adresse e-mail principale et l’adresse e-mail principale d’origine est détruite. Ce cas déclenchait auparavant une erreur de connexion, donc le comportement semble intentionnel. J’ai passé beaucoup trop de temps à suivre où cela se produit : discourse/app/models/user.rb at main · discourse/discourse · GitHub. (L’ancienne adresse e-mail principale est détruite lors de la sauvegarde de l’utilisateur.)
Est-ce important pour que, si l’e-mail principal échoue, un administrateur ou un modérateur puisse tenter de contacter manuellement le titulaire du compte avec l’e-mail secondaire ?
Sinon, un compte serait généralement résilié s’il n’y a pas d’adresse e-mail valide. Cependant, certains e-mails reviennent comme étant temporairement non livrables si quelqu’un a des paiements en souffrance pour celui-ci.
Cela ajoute certainement un peu de flexibilité. Le cas d’un utilisateur perdant l’accès à l’adresse e-mail qu’il a utilisée pour créer son compte Discourse est délicat à gérer.
Oui, cela peut être difficile d’authentifier quelqu’un qui prétend avoir un compte mais n’a pas accès à son e-mail principal ou ne se souvient pas de son mot de passe. J’ai mis une deuxième adresse e-mail pour mon compte ici qui utilise des serveurs différents, donc j’espère que s’il y a un problème avec le principal, l’autre fonctionnera.