How can I automatically confirm a secondary email address?

Support
1

I’ve seen a few topics touch on this issue, but nothing quite seems to address it.

Basically, our company was purchased. This means all users are moving from @old_company.com to @new_company.com

I have a map of old to new email addresses. What I would like to do is add the @new_company.com email address for a user and automatically confirm it. Otherwise they need to go through the confirmation emails themselves, which realistically won’t happen.

Is there any way I can add a secondardy email as admin and automatically confirm it?

Simon mentions the following

But it’s not clear to me how this works. How can it sync an email address to an account, if the address is not yet confirmed? Does this mean I should/could

  1. add secondary email for user via api
  2. (maybe) disable outgoing email for 10 minutes so no confirmation email is sent
  3. enable saml sync email
  4. user accounts confirm and update when they sign in with saml

Note, we are also changing saml provider in this example

Even though the secondary email has not been confirmed, does the above setup mean that when they try to log in with the email for the first time, it will be automatically confirmed and tied to the account?

2 Likes
4

image

Just as a note, one issue I misunderstood was the confirmation email. As admin you get two emails, one to confirm your old email, then a second to confirm the change.

I assumed this applied to all users, but with the setting in the image above, you can set it to apply to only staff. This means users would only get the one email to confirm the change.

Still need to figure out how to automatically confirm the email for the user though :thinking:

1 Like
5

I’m not sure there is a way to automatically confirm through the UI/API. :thinking: I think if there’s SSO then the email/identity confirmation is handled by them? In which case using the sso_sync would pull in the already confirmed data/email and use that as ‘trustworthy’.

A little bit of fact-checking later… :slight_smile:

The /admin/users/sync_sso is only for DiscourseConnect. I think you already knew that, but I’ll say it out loud for anyone reading this later.

But there’s also the auth_overrides_emails admin setting which may be useful for this.

Essentially, if your SAML provider is sending a verified email, and auth_overrides_emails is set, Discourse will start using the new email without any confirmation being emailed out. :+1:

2 Likes
9

This is not a direct answer to your question, but: In the case of mass-renaming of email-addresses, you could do it via 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

If you favor adding a secondary email address:

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 Like
10

Thanks for the suggestions. I gave them a try in the following way:

1. Add secondary email to user via api

The email is unconfirmed, but tied to the account
image

2. Configure the following settings:

image

image

image

  • I forgot to set the saml sync to true, however I don’t think that would have affected the outcome. The issue still seems to be conflict in terms of the email confirmation.

3. Result

The result was the a new user account was created based on the new company email. Worst case I could merge these, but that is a really nasty worst case.

I can still see the unconfirmed email in the old account. I try to resend the confirmation just to see what would happen but I get a 403 error(Forbidden).

It looks like the email needs to be confirmed first before we can syncronise them :confused:

Unless there’s something I’m missing, it looks like I need a way to confirm the second email.

I wonder if this still has the same issue in terms of confirmation, or are they assumed to be confirmed? An additional complexity is that the user part of user@company.com has also changed. But I suspect that would mean we run through a csv of mappings between the old and new emails.

11

I was more thinking of changing the email in the SSO, enabling auth overrides emails, and then logging into your account via your SSO as normal.

I may be missing something.

1 Like
12

I think it might be doing this, in that it is validating a SAML account based on the email address and SAML server used to log in. The problem is that it’s a completely different SAML IDP (New Company).

Consequently it correctly over-rides/creates the email to be the SAML email, but it does this for a brand new account because the Discourse account is not associated to the new email address.

However, if the existing account has the new saml email addres already confirmed in Discourse, then the login is smooth and it becomes their new saml login email.

13

Hmmm. :thinking: I think I was maybe working on the assumption that the move to the new IDP would have mapped them across based on an external id of some sort.

I think it is possible to activate/confirm the email through the rails console by adding in the token info too. Something like:

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 Likes
14

To the best of my knowledge this hasn’t happened. For another platform we needed to get a list of the emails ourselves and do the mapping.

It looks more and more like this is the way to proceed. We’re hosted by you guys so I’ll pass this on to our CSM and follow up on this topic with any progress.

2 Likes