如何自动确认辅助邮箱地址？

支持
1

我看到一些帖子讨论过这个问题，但似乎没有一个完全解决。

基本上，我们的公司被收购了。这意味着所有用户都将从 @old_company.com 迁移到 @new_company.com。

我有一个旧电子邮件地址到新电子邮件地址的映射。我想做的是为用户添加 @new_company.com 电子邮件地址并自动确认它。否则，他们需要自己处理确认邮件，而这实际上不会发生。

作为管理员，我有什么办法可以添加辅助电子邮件地址并自动确认它吗？

Simon 提到了以下内容：

但我不清楚这如何工作。如果地址尚未确认，它如何能将电子邮件地址同步到帐户？这是否意味着我应该/可以：

  1. 通过 API 为用户添加辅助电子邮件地址
  2. （也许）禁用电子邮件发送 10 分钟，以免发送确认邮件
  3. 启用 saml sync email
  4. 用户帐户在通过 SAML 登录时确认并更新

注意，在此示例中我们还将更改 SAML 提供商

即使辅助电子邮件地址尚未确认，上述设置是否意味着当他们第一次尝试使用该电子邮件地址登录时，它将被自动确认并与帐户关联？

2 个赞
4

image

只是作为一点说明，我之前误解的一个问题是确认电子邮件。作为管理员，您会收到两封电子邮件，一封用于确认您的旧电子邮件，第二封用于确认更改。

我曾以为这适用于所有用户，但通过上面图片中的设置，您可以将其设置为仅适用于员工。这意味着用户只会收到一封确认更改的电子邮件。

仍然需要弄清楚如何为用户自动确认电子邮件 :thinking:

1 个赞
5

我不确定是否有办法通过 UI/API 自动确认。 :thinking: 我认为如果启用了 SSO，那么电子邮件/身份验证将由他们处理？在这种情况下，使用 sso_sync 将会拉取已确认的数据/电子邮件并将其用作“可信”信息。

稍作事实核查…… :slight_smile:

/admin/users/sync_sso 仅用于 DiscourseConnect。我想你已经知道了，但我还是大声说出来，方便以后阅读此内容的人。

但还有一个 auth_overrides_emails 管理员设置，这可能对此有所帮助。

基本上，如果你的 SAML 提供商发送了经过验证的电子邮件，并且设置了 auth_overrides_emails，Discourse 将开始使用新电子邮件，而无需发送任何确认邮件。 :+1:

2 个赞
9

这不是对您问题的直接回答，但：在批量重命名电子邮件地址的情况下，您可以通过 rails console 进行操作：

o = "@old_company.com" 
n = "@new_company.com"
UserEmail.where("email LIKE ?","%#{o}").each do |ue| 
  ue.email.sub! o,n 
  ue.save! 
end

如果您倾向于添加辅助电子邮件地址：

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
1 个赞
10

感谢您的建议。我尝试了以下方法：

1. 通过 API 为用户添加辅助邮箱

邮箱未确认，但已关联到账户

image
image577×304 14.7 KB

2. 配置以下设置：

image

image

image

  • 我忘记将 SAML 同步设置为 true，但我不认为这会影响结果。问题似乎仍然是邮箱确认方面的冲突。

3. 结果

结果是基于新的公司邮箱创建了一个新的用户账户。最坏的情况下，我可以合并它们，但这是一种非常糟糕的糟糕情况。

我仍然可以在旧账户中看到未确认的邮箱。我尝试重新发送确认邮件以查看会发生什么，但收到 403 错误（禁止）。

看起来我们需要先确认邮箱，然后才能同步它们 :confused:

除非我遗漏了什么，否则我需要一种方法来确认第二个邮箱。

我想知道这在确认方面是否仍然存在同样的问题，或者它们是否被假定为已确认？一个额外的复杂性是 user@company.com 中的 user 部分也已更改。但我怀疑这是否意味着我们需要通过 CSV 文件处理旧邮箱和新邮箱之间的映射。

11

我原本是想在 SSO 中更改电子邮件，启用 auth overrides emails，然后像平常一样通过 SSO 登录您的帐户。

我可能遗漏了什么。

1 个赞
12

我认为这可能是这样做的，即它根据用于登录的电子邮件地址和SAML服务器来验证SAML帐户。问题是这是一个完全不同的SAML IDP（新公司）。

因此，它正确地覆盖/创建了电子邮件为SAML电子邮件，但它为全新的帐户执行此操作，因为Discourse帐户未与新电子邮件地址关联。

但是，如果现有帐户已经在Discourse中确认了新的SAML电子邮件地址，那么登录将顺利进行，并且它将成为他们的新的SAML登录电子邮件。

13

嗯。 :thinking: 我认为我可能基于某种外部 ID 映射了它们，假设迁移到新的 IDP 会将它们映射过去。

我认为可以通过 Rails 控制台激活/确认电子邮件，同时添加令牌信息。类似这样：

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
2 个赞
14

据我所知，这并没有发生。对于另一个平台，我们需要自己获取电子邮件列表并进行映射。

看来这越来越像是要采取的途径了。我们是由你们托管的，所以我会把这个问题转达给我们的客户成功经理，并在此主题上跟进任何进展。

2 个赞