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:
adicionar um e-mail secundário para o usuário via API
(talvez) desativar o envio de e-mails por 10 minutos para que nenhum e-mail de confirmação seja enviado
habilitar saml sync email
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?
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
Não tenho certeza se há uma maneira de confirmar automaticamente através da interface do usuário/API. 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…
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.
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
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
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.
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.
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.
