Alterando o e-mail de um usuário

Contribuir Bug
1

Estou um pouco confuso sobre o processo quando um administrador altera o endereço de e-mail de um usuário.

Há algumas coisas que não entendo e há um bug (por isso estou postando isso em Contribute > Bug e não em Support).

  • De acordo com esta pull request, o funcionamento deveria ser assim:

Quando um administrador altera o e-mail de um usuário na página de preferências desse usuário:

  • O usuário não receberá um e-mail para confirmar a alteração do e-mail. Em vez disso, receberá um e-mail de redefinição de senha para que possa definir a senha da conta no novo endereço de e-mail.
  • O usuário ainda receberá um e-mail no endereço antigo informando que a alteração foi feita.

#1 Não entendo por que um e-mail de redefinição de senha está sendo enviado (“para que possam definir a senha da conta”). Eles não precisam alterar a senha? E a experiência do usuário é confusa — o usuário não espera receber um e-mail de redefinição de senha, não há texto explicativo, apenas diz: “Alguém solicitou a redefinição da sua senha no [nome do fórum]”.

#2 Esse e-mail de redefinição de senha é enviado para o endereço antigo em vez do endereço de e-mail novo.

Embora o e-mail do usuário seja atualizado em update_user_email na linha 46, o objeto @user não é recarregado e ainda contém o endereço de e-mail antigo.

#3 Se o administrador é o usuário que está realizando a ação e o usuário afetado não é membro da equipe, nenhum e-mail de confirmação é enviado conforme especificado acima. No entanto, após alterar o endereço de e-mail, o administrador recebe a seguinte mensagem de sucesso: “Enviamos um e-mail para esse endereço. Siga as instruções de confirmação”.

#4 Por que o usuário não precisa confirmar seu novo endereço de e-mail? A pull request faz referência a este tópico, mas parece que faltam muitas postagens nele. Contudo, o tópico ainda menciona: “Para um usuário comum, o único endereço de e-mail que precisa ser verificado é o endereço de e-mail NOVO”. EDIT: ah, espere, veja #6 / #7.

#5 Esse processo, em que um administrador altera o e-mail do usuário, é tipicamente usado quando o endereço de e-mail antigo não está mais acessível (suponho). Por que ainda há uma notificação sendo enviada para o endereço antigo?

#6 Quando esse usuário tenta fazer login, aparece um popup:

Você ainda não pode fazer login. Enviamos anteriormente um e-mail de ativação para você no endereço de e-mail antigo. Siga as instruções contidas nesse e-mail para ativar sua conta.

  • Não houve nenhum e-mail desse tipo
  • O endereço de e-mail antigo é mencionado

Ao pressionar o botão “Reenviar”, a mensagem diz:

Enviamos outro e-mail de ativação para você no endereço de e-mail novo. Pode levar alguns minutos para chegar; verifique também sua pasta de spam.

#7 Esse e-mail de ativação realmente chega ao novo endereço de e-mail e tem o título “confirme sua nova conta” (e não “confirme seu novo endereço de e-mail”).

Isso não deveria ser assim:

Um único e-mail é enviado para o novo endereço de e-mail, dizendo: “Seu endereço de e-mail foi alterado por [nome do administrador]. Clique no seguinte link para confirmar [link].”

Edição: #8 O endereço de e-mail pode ser alterado por um administrador a partir do perfil público do usuário (/u/username), mas não a partir da página de administração desse usuário (/admin/users/id/username). Isso é contra-intuitivo.

10 curtidas
2

Conseguimos reproduzir isso @tshenry? Houve regressão aqui?

2 curtidas
4

Vou começar descrevendo o fluxo atual como o estou observando (a maioria, se não todos, ou isso se alinha com o que @RGJ detalhou):

  1. O administrador acessa as preferências de um usuário não-staff e altera seu endereço de e-mail:

    Screen Shot 2020-09-24 at 4.16.04 PM
    Screen Shot 2020-09-24 at 4.16.04 PM1758×590 35.2 KB

    Após o envio, o administrador vê a seguinte mensagem:

    Enviamos um e-mail para esse endereço. Por favor, siga as instruções de confirmação.

  2. A mensagem acima não parece precisa, pois DOIS e-mails são enviados para o endereço de e-mail antigo:

    [Demo] Seu endereço de e-mail foi alterado

    Esta é uma mensagem automatizada para informar que seu endereço de e-mail para
    Demo foi alterado. Se isso foi feito por engano, entre em contato com
    um administrador do site.

    Seu endereço de e-mail foi alterado para:

    new@email.com

    [Demo] Redefinição de senha

    Alguém solicitou a redefinição da sua senha no Demo.

    Se não foi você, pode ignorar este e-mail com segurança.

    Clique no seguinte link para escolher uma nova senha:
    https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2

  3. Testei três cenários separados a partir deste ponto. Cada item de lista representa um cenário distinto:

    • O usuário tem acesso ao e-mail antigo e segue o link de redefinição de senha. Ao atualizar sua senha, ele é logado. A partir daí, pode fazer login com seu nome de usuário ou o endereço de e-mail ANTIGO. O novo e-mail não parece estar ativo neste momento.

    • O usuário tenta fazer login com seu nome de usuário ou o endereço de e-mail novo e recebe a seguinte mensagem:

      Screen Shot 2020-09-24 at 4.38.01 PM
      Screen Shot 2020-09-24 at 4.38.01 PM1418×394 35.5 KB

      Opção 1: Ao clicar em reenviar, a seguinte mensagem é exibida (note que desta vez menciona o novo endereço de e-mail):

      Screen Shot 2020-09-24 at 4.59.42 PM
      Screen Shot 2020-09-24 at 4.59.42 PM1418×390 27.8 KB

      Um e-mail é, de fato, enviado para o endereço de e-mail novo:

      [Demo] Confirme sua nova conta

      Bem-vindo ao Demo!

      Clique no seguinte link para confirmar e ativar sua nova conta:
      https://example.discourse.site/u/activate-account/74d53d7d2cf20dsbc360614844c653s2

      Se o link acima não for clicável, tente copiá-lo e colá-lo na barra de endereços do seu navegador.

      Ao seguir o link, o usuário passa por algumas páginas de ativação de nova conta. No final, ele faz login com sucesso. A partir desse ponto, o usuário pode fazer login com seu nome de usuário ou o e-mail ANTIGO. O novo e-mail não parece estar ativo neste momento.

      Opção 2: Ao clicar no botão alterar endereço de e-mail, a seguinte tela é exibida. O botão Atualizar Endereço de E-mail está desabilitado quando o novo endereço de e-mail está no campo de texto, sugerindo que o novo e-mail já está ativo (mas isso não parece ser verdade).

      Screen Shot 2020-09-24 at 5.17.31 PM
      Screen Shot 2020-09-24 at 5.17.31 PM938×492 27.2 KB

    • O usuário inicia uma redefinição de senha. O e-mail é enviado para o endereço de e-mail novo e o usuário pode fazer login com o link. Como nos outros cenários, o usuário pode fazer login com seu nome de usuário ou o e-mail ANTIGO. O novo e-mail não parece estar ativo neste momento.

Portanto, estamos definitivamente reproduzindo problemas aqui. É algo complicado de descrever claramente, mas espero que, entre a mensagem original e esta descrição, fique compreensível. Certamente parecem existir algumas coisas que precisam ser corrigidas.

@martin, sei que você já mexeu com essa parte do núcleo no passado. Você poderia dar sua opinião quando tiver um momento?

9 curtidas
5

Por que isso regrediu? :thinking:

edit: Também posso confirmar que regrediu. Ao editar o e-mail de um usuário comum, a confirmação e outras coisas são enviadas para o e-mail ANTIGO. Não era assim que funcionava no passado..

4 curtidas
6

Aquela sensação de familiaridade desconfortável ao ler a descrição do pull request citado e perceber que você é o culpado…

Obrigado pelas instruções detalhadas @tshenry e @RGJ. Vou colocar isso no topo da minha lista para corrigir esta semana.

4 curtidas
7

Tudo bem, agora entendi o assunto. Procurei no tópico antigo sobre comentários excluídos para ver o histórico. Encontrei isso do @sam, que agora me lembro:

O caso de redefinição de e-mail pelo administrador é muito diferente; na verdade, trata-se de o administrador redefinir o e-mail e a senha. Pois se o usuário tivesse acesso à conta, poderia fazer tudo usando o autoatendimento.

Então, estamos dizendo que, como é o administrador quem está alterando o e-mail, deveria ser enviada uma e-mail de redefinição de senha, porque, se o usuário tivesse acesso ao e-mail antigo, poderia simplesmente… fazer login e fazer isso sozinho? Mas o e-mail de redefinição de senha também atua como uma confirmação. Sem concluir o processo de redefinição de senha (o que é impossível no momento, pois é enviado para o e-mail antigo), o novo e-mail não fica “confirmado”, e é isso que faz este modal aparecer:

image
image1124×292 28.1 KB

O problema em que o e-mail de redefinição de senha é enviado para o endereço antigo é facilmente corrigido, e pelo menos chegaremos a um estado em que o processo de redefinição poderá ser seguido:

Além disso, como o e-mail de redefinição de senha é atualmente enviado para o e-mail antigo, quando confirmado, ele confirma o endereço errado e redefine o e-mail do usuário de volta para o antigo.

Vou alterar a mensagem exibida ao administrador que está alterando o e-mail para deixar claro que o usuário deve clicar no link do novo e-mail e alterar sua senha para que a mudança tenha efeito total (e também corrigir o problema do e-mail errado).

4 curtidas
8

Espere. Não entendi isso.

Existe uma diferença entre o usuário conseguir acessar o e-mail antigo e o usuário precisar de uma redefinição de senha para sua conta no Discourse. O primeiro de forma alguma implica o segundo; são situações totalmente diferentes.

Um grande número de alterações de e-mail feitas por administradores ocorre também porque o usuário não sabe como fazer isso ou porque o administrador precisa suspender temporariamente a restrição email_editable = false.

Acho muito confuso que uma redefinição de senha sirva também como confirmação de e-mail. Pessoalmente, eu nem responderia ao e-mail de redefinição de senha, já que não solicitei, e não perceberia que se tratava de uma etapa necessária de confirmação (e acho que não é; um e-mail de confirmação comum seria suficiente?).

4 curtidas
9

Pode estar relacionado:

Quando um dos usuários do meu fórum tenta redefinir sua senha hoje (executando a versão mais recente do Discourse até esta manhã), ele recebe o e-mail, mas depois um erro ao seguir o link do e-mail:

Screen Shot 2020-09-28 at 9.41.04 AM
Screen Shot 2020-09-28 at 9.41.04 AM868×696 46.6 KB

Ele recebe esse erro em vários navegadores e não está usando um bloqueador de anúncios.

Quando vou à página de Preferências da conta dele e clico em “Enviar e-mail de redefinição de senha”, também recebo uma mensagem de erro lá:

Screen Shot 2020-09-28 at 9.44.10 AM
Screen Shot 2020-09-28 at 9.44.10 AM630×336 12.4 KB

Antes de mostrar “(erro)” ao lado do botão, ele pisca brevemente “(enviando e-mail)”. Parece que nenhum e-mail foi enviado, no entanto. Posso confirmar que outros e-mails do fórum estão sendo enviados normalmente hoje.

Esse recurso estava funcionando corretamente antes… parece ter quebrado em algum momento na última semana.

10

Verifique os registros de erro do Discourse no navegador da web enquanto estiver logado como administrador; deve haver um relatório de erro lá com mais detalhes.

11

Aqui está a entrada de erro:

398 Exceção de Job: A origem de cópia especificada é maior que o tamanho máximo permitido para uma origem de cópia: 5368709120

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/request.rb:70:in `send_request'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix'

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'

/var/www/discourse/app/jobs/base.rb:221:in `block in perform'

/var/www/discourse/app/jobs/base.rb:217:in `each'

/var/www/discourse/app/jobs/base.rb:217:in `perform'

sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'

sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'

sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'

sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'

sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'
1 curtida
12

Não, isso é absolutamente sem relação.
Tente limpar os logs e forçar esse erro a ocorrer, depois verifique os logs novamente.

13

Então os logs permanecem em branco após o erro ocorrer.

14

Entendo o seu ponto de vista; para mim, a ideia de usar a redefinição de senha como confirmação me confundiu ontem. Acredito que isso poderia ser uma opção secundária para o administrador ao alterar o e-mail de um usuário: uma caixa de seleção dizendo “Redefinir também a senha do usuário”. Vou mesclar o PR que tenho para uma correção como está, pois o processo está totalmente quebrado no momento.

Gostaria que @sam se manifestasse sobre um novo processo/fluxo, já que Sam originalmente falou sobre a razão por trás do fluxo de redefinição de senha:

  1. O administrador altera o e-mail do usuário. Ele tem a opção de redefinir a senha do usuário ao mesmo tempo.
  2. O usuário recebe um e-mail no novo endereço pedindo confirmação para alterar o e-mail.
    • Se disserem Sim, alteramos o e-mail. Enviamos um e-mail para o endereço antigo informando que o e-mail foi alterado.
    • Se disserem Não, não fazemos nada.
  3. Se o administrador tiver especificado que queria uma redefinição no passo 1., assim que o usuário confirmar a alteração do e-mail, ele recebe um e-mail de redefinição de senha no novo endereço.

Acho que isso seria muito mais claro, e a redefinição de senha não teria nada a ver com a confirmação da alteração do e-mail.

2 curtidas
15

Sim, não consigo ver por que essas duas coisas estariam relacionadas de alguma forma?

1 curtida
16

Vejo uma ótima nova commit mesclada que as pessoas vão adorar :smiley:

3 curtidas
17

Obrigado, isso apenas irá mesclar uma correção para o estado “completamente quebrado” das coisas. Outro PR está a caminho!

Foi feito dessa forma com base nas discussões no tópico anterior com o Sam. Vou seguir com o novo processo para levantar o véu da confusão e eliminar o vínculo entre as coisas não relacionadas.

4 curtidas
18

Acabei de mesclar este PR que faz o seguinte:

  • Altera o fluxo de alteração de e-mail para usuários no painel administrativo, de modo que o usuário receba um e-mail para confirmar a mudança
  • Agora registramos quem solicitou a alteração de e-mail
  • Se o solicitante for um administrador e não o próprio usuário, isso é mencionado no e-mail enviado ao usuário
  • Também tornamos a rota de confirmação de alteração de e-mail acessível a usuários anônimos, para que possa ser clicada pelo usuário mesmo que ele não tenha acesso à sua conta. Se houver um usuário logado, garantimos que a confirmação corresponda ao usuário atual.

Esperamos que isso torne o processo muito mais claro!

4 curtidas