аккаунт одного из наших пользователей был скомпрометирован. Процедура устранения последствий была далека от идеала.
Для этого потребовалась консоль Rails:
Принудительная смена адреса электронной почты
Принудительная смена пароля на случайный, чтобы потребовать сброса пароля по электронной почте
Завершение всех активных сессий
Кроме того, мы обнаружили, что изменение адреса электронной почты отображалось только в журналах исходящей почты и нигде больше.
AI-детектор спама перехватывал спам для новых аккаунтов, но не был включен для этого уровня доверия и количества публикаций. Возможно, стоит добавить возможность включения AI-детектора спама при смене страны и/или отсутствии публикаций в течение года.
Спасибо всем за отличное программное обеспечение на протяжении многих лет, несмотря на такие незначительные недостатки, как этот.
Все эти действия также можно выполнить на странице «Администрирование > Пользователи». Не понимаю, что могло создать у вас впечатление, будто это возможно только из консоли?
Изменение адреса электронной почты отправляет запрос на подтверждение на новый адрес, но не удаляет старый сразу.
Кнопка «Деактивировать учётную запись» может быть верной, но неясно, требует ли она сброса пароля по электронной почте.
Мне так и не удалось найти кнопку завершить все сеансы. Смена пароля через функцию «принять роль» теоретически работает, но это довольно запутанно, особенно когда учётная запись пользователя настроена на язык, которым администратор или модератор не владеет.
Если у вас есть веские основания полагать, что электронная почта пользователя скомпрометирована, что, в свою очередь, привело к компрометации его учётной записи Discourse, вы можете как администратор изменить её адрес и удалить старый.
Вы также можете просто пометить учётную запись как неактивную. Это потребует повторной проверки электронной почты и фактически аннулирует все существующие сеансы.
Нет, я пробовал это сделать, но у меня не получилось, так как система отправляет письмо с подтверждением на новый адрес электронной почты. Пока ссылка в этом письме не будет активирована, старый адрес остаётся в базе данных и, вероятно, считается действительным.
Я намеренно открыл это как баг-репорт/запрос на новую функцию, чтобы в будущем, возможно, улучшить ситуацию. Конкретная задача уже выполнена, и пользователь получил свой аккаунт обратно.
Я не уверен, что это баг. Это даже не пограничный случай, на мой взгляд. Небрежное отношение пользователей к своим данным или личности — явление нечастое, и существующих мер защиты достаточно. Упрощение этого процесса может привести к большему количеству побочных эффектов. Это не то, с чем людям приходится сталкиваться ежедневно, и если ситуация действительно критическая, администраторы знают, как её смягчить. Возможно, текст сообщения можно немного улучшить, но точно не за счёт добавления новых опций в интерфейс.
Что плохого в кнопках «Отключить все сеансы», «Принудительно сменить пароль» и «Принудительно сменить электронную почту»? Видел такое в другом программном обеспечении.
Недавно я подал запрос на добавление функции для администраторов, позволяющей более гибко управлять адресами электронной почты пользователей, что также решит эту задачу:
Да, это нечастое событие (к счастью). Но когда оно (или что-то подобное) происходит, оно становится критическим и требует быстрого реагирования. Не время изучать, как работать в Bash / консоли Rails, или подавать заявку в службу поддержки!
Однако временная деактивация аккаунта не требует работы с консолью Rails. За почти 10 лет управления различными сообществами Discourse я ни разу не сталкивался с ситуацией, которая требовала бы использования консоли Rails (за исключением миграции сообществ или выполнения массовых действий). Я понимаю, что могут быть случаи, когда внесение изменений напрямую в базу данных считается более безопасным вариантом для предотвращения дальнейшего ущерба, но не уверен, что добавление дополнительных опций в профили пользователей или страницы администратора имеет смысл, учитывая, что обе они уже и так перегружены.
Верно — и это довольно эффективно остановит их на месте.
Я также почти уверен, что принудительное слияние учётных записей администратором с последующим удалением проблемного (теперь неосновного) адреса электронной почты будет эффективным — и это также можно использовать для принудительной смены адресов электронной почты в других ситуациях. Однако это во многом является обходным путём.