Como posso confirmar automaticamente um endereço de e-mail secundário?

Suporte
1

Vi alguns tópicos abordarem essa questão, mas nada parece resolvê-la completamente.

Basicamente, nossa empresa foi comprada. Isso significa que todos os usuários estão migrando de @old_company.com para @new_company.com.

Tenho um mapeamento de endereços de e-mail antigos para novos. O que eu gostaria de fazer é adicionar o endereço de e-mail @new_company.com para um usuário e confirmá-lo automaticamente. Caso contrário, eles precisarão passar pelos e-mails de confirmação, o que, realisticamente, não acontecerá.

Existe alguma maneira de eu adicionar um e-mail secundário como administrador e confirmá-lo automaticamente?

Simon menciona o seguinte:

Mas não está claro para mim como isso funciona. Como ele pode sincronizar um endereço de e-mail com uma conta, se o endereço ainda não foi confirmado? Isso significa que eu deveria/poderia:

  1. adicionar um e-mail secundário para o usuário via API
  2. (talvez) desativar o envio de e-mails por 10 minutos para que nenhum e-mail de confirmação seja enviado
  3. habilitar saml sync email
  4. as contas de usuário confirmam e atualizam quando entram com o SAML

Nota: também estamos mudando o provedor SAML neste exemplo

Mesmo que o e-mail secundário não tenha sido confirmado, a configuração acima significa que, quando eles tentarem fazer login com o e-mail pela primeira vez, ele será automaticamente confirmado e vinculado à conta?

2 curtidas
4

image

Apenas como observação, um problema que interpretei mal foi o e-mail de confirmação. Como administrador, você recebe dois e-mails, um para confirmar seu e-mail antigo e um segundo para confirmar a alteração.

Presumi que isso se aplicava a todos os usuários, mas com a configuração na imagem acima, você pode definir para se aplicar apenas à equipe. Isso significa que os usuários receberiam apenas um e-mail para confirmar a alteração.

Ainda preciso descobrir como confirmar automaticamente o e-mail para o usuário :thinking:

1 curtida
5

Não tenho certeza se há uma maneira de confirmar automaticamente através da interface do usuário/API. :thinking: Acho que se houver SSO, a confirmação de e-mail/identidade é tratada por eles? Nesse caso, usar o sso_sync traria os dados/e-mail já confirmados e os usaria como ‘confiáveis’.

Um pouco de checagem de fatos depois… :slight_smile:

O /admin/users/sync_sso é apenas para DiscourseConnect. Acho que você já sabia disso, mas vou dizer em voz alta para quem ler isso mais tarde.

Mas também existe a configuração de administrador auth_overrides_emails, que pode ser útil para isso.

Essencialmente, se o seu provedor SAML estiver enviando um e-mail verificado e auth_overrides_emails estiver definido, o Discourse começará a usar o novo e-mail sem que nenhuma confirmação seja enviada por e-mail. :+1:

2 curtidas
9

Esta não é uma resposta direta à sua pergunta, mas: No caso de renomeação em massa de endereços de e-mail, você pode fazer isso via 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

Se você preferir adicionar um endereço de e-mail secundário:

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

Obrigado pelas sugestões. Eu as experimentei da seguinte maneira:

1. Adicionar e-mail secundário ao usuário via API

O e-mail não está confirmado, mas está vinculado à conta

image
image577×304 14.7 KB

2. Configurar as seguintes configurações:

image

image

image

  • Esqueci de definir a sincronização saml como true, no entanto, não acho que isso teria afetado o resultado. O problema ainda parece ser um conflito em termos de confirmação de e-mail.

3. Resultado

O resultado foi que uma nova conta de usuário foi criada com base no novo e-mail da empresa. No pior dos casos, eu poderia mesclar essas contas, mas esse é um pior caso realmente desagradável.

Ainda consigo ver o e-mail não confirmado na conta antiga. Tento reenviar a confirmação apenas para ver o que aconteceria, mas recebo um erro 403 (Proibido).

Parece que o e-mail precisa ser confirmado primeiro antes que possamos sincronizá-los :confused:

A menos que eu esteja perdendo alguma coisa, parece que preciso de uma maneira de confirmar o segundo e-mail.

Eu me pergunto se isso ainda tem o mesmo problema em termos de confirmação, ou se eles são considerados confirmados? Uma complexidade adicional é que a parte do usuário de user@company.com também mudou. Mas suspeito que isso significaria que passaríamos por um CSV de mapeamentos entre os e-mails antigos e os novos.

11

Eu estava pensando mais em alterar o e-mail no SSO, habilitando auth overrides emails e, em seguida, fazendo login na sua conta via SSO normalmente.

Talvez eu esteja perdendo alguma coisa.

1 curtida
12

Eu acho que pode estar fazendo isso, validando uma conta SAML com base no endereço de e-mail e no servidor SAML usados para fazer login. O problema é que é um IDP SAML completamente diferente (Nova Empresa).

Consequentemente, ele substitui/cria corretamente o e-mail para ser o e-mail SAML, mas faz isso para uma conta totalmente nova porque a conta Discourse não está associada ao novo endereço de e-mail.

No entanto, se a conta existente já tiver o novo endereço de e-mail SAML confirmado no Discourse, o login será tranquilo e se tornará o novo e-mail de login SAML.

13

Hmmm. :thinking: Acho que eu estava trabalhando com a suposição de que a mudança para o novo IDP os teria mapeado com base em um ID externo de algum tipo.

Acho que é possível ativar/confirmar o e-mail através do console do Rails adicionando também as informações do token. Algo como:

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

Até onde sei, isso não aconteceu. Para outra plataforma, precisamos de obter uma lista de e-mails nós mesmos e fazer o mapeamento.

Parece cada vez mais que este é o caminho a seguir. Somos hospedados por vocês, então passarei isto ao nosso CSM e acompanharei este tópico com qualquer progresso.

2 curtidas