Lidar com uma conta de usuário hackeada não deveria exigir o console

Olá a todos,

a conta de um de nossos usuários foi comprometida. O fluxo de trabalho para mitigar isso estava longe de ser ideal.

O console do Rails foi necessário para:

  • Forçar a alteração do endereço de e-mail
  • Forçar a alteração da senha para algo aleatório para forçar um redefinição de senha via e-mail
  • Encerrar todas as sessões ativas

Além disso, descobrimos que a alteração do e-mail só era visível nos logs de e-mail de saída e em nenhum outro lugar.

O detector de spam com IA detectou esse spam para novas contas, mas não estava habilitado para esse nível de confiança e número de publicações. Talvez seja uma boa ideia incluir a opção de habilitar o detector de spam com IA para alteração de país e/ou nenhuma publicação em mais de um ano.

Obrigado a todos pelo ótimo software ao longo dos anos, apesar de pequenas falhas como esta.

Todas essas ações também podem ser realizadas na página Admin > Usuários. Não tenho certeza do que lhe deu a impressão de que isso só era possível pelo console?

A alteração do e-mail envia um aviso de confirmação para o novo, mas não remove o antigo imediatamente.
O botão de desativar conta pode ter sido o correto, mas não está claramente rotulado se isso força uma redefinição de senha via e-mail.
Eu ainda não consegui encontrar um botão de encerrar todas as sessões e, em teoria, a alteração de senha via personificação funciona, mas é muito confusa, especialmente quando os usuários configuraram suas contas para um idioma que o administrador/moderador não fala.

Se você tiver razões plausíveis de que o e-mail de um usuário foi comprometido, o que, por sua vez, resultou no comprometimento de sua conta no Discourse, você pode, como administrador, alterar o e-mail dele e remover o e-mail antigo.

Você pode simplesmente marcar uma conta como desativada, o que forçará uma nova verificação de e-mail e, essencialmente, anulará todas as sessões existentes.

Não, eu tentei isso e não consegui fazer, porque gerou um e-mail de confirmação para o novo endereço de e-mail e, até que isso fosse clicado, o antigo ainda estava no banco de dados e provavelmente válido.

Neste caso, a suspensão pode ser usada em seu lugar.

Abri isto como um relatório de bug/solicitação de recurso de propósito para possivelmente melhorá-lo mais tarde, a tarefa concreta já foi concluída e o usuário recuperou sua conta.

Não tenho tanta certeza de que isso seja um bug. Isso nem sequer é um caso extremo na minha opinião. Usuários serem descuidados com seus dados ou identidade não é uma ocorrência comum e há proteções suficientes presentes. Tornar este processo mais fácil potencialmente teria mais efeitos colaterais. Isso não é algo com que as pessoas devam ter que lidar diariamente e, se a situação for crítica o suficiente, os administradores sabem como contornar a mitigação. Talvez o texto pudesse ser um pouco melhorado, mas definitivamente não a favor de adicionar mais opções à interface do usuário.

Além disso, não há um botão para aumentar o tempo de uma suspensão sem primeiro suspendê-la.

O que há de errado com um botão de desconectar todas as sessões e forçar nova senha e forçar alteração de e-mail? Já vi isso em outro software.

Funcionários usando isso maliciosamente por uma vez.

Recentemente, enviei uma solicitação de funcionalidade para ter mais controle sobre os endereços de e-mail dos usuários para administradores, o que também abordaria este caso de uso:

Sim, não é um evento comum (felizmente). Mas é crítico quando ocorre (ou algo semelhante), e requer uma resposta rápida. Não é hora de aprender a navegar pelo Bash / console do Rails ou abrir um chamado de suporte!

Mas desativar a conta no interim não exige navegar pelo console do rails. Em quase 10 anos gerenciando várias comunidades do Discourse, nunca encontrei uma situação que exigisse o console do rails (além de migrar comunidades ou executar ações em massa). Eu aprecio o fato de que pode haver casos em que fazer alterações diretamente no db seria considerado a aposta mais segura para evitar mais danos, mas não tenho certeza se adicionar mais opções aos perfis de usuário ou às páginas de administrador faz sentido, visto que ambos já estão bem lotados como estão.

Verdade - e os impedirá imediatamente de forma bem eficaz.

Também tenho quase certeza de que uma mesclagem forçada de contas por um administrador com a exclusão subsequente do endereço de e-mail ofensivo (agora não primário) seria eficaz - e também poderia ser usada para forçar alterações de e-mail em outras situações. Mas isso é muito um contorno.