Автоматически удалять пользователей, отмеченных системой?

Привет!

Каждый день я отмечаю дюжину спам-аккаунтов с пометкой «Этот новый пользователь ввёл информацию профиля, не прочитав ни одной темы или поста».

За два года у нас не было ни одного ложного срабатывания.

Поэтому я думаю, что мы могли бы автоматически удалять такие аккаунты, если они помечены по этой конкретной причине.

Возможно, перед удалением можно автоматически отправлять письмо получателю, уведомляя о том, что аккаунт был удалён автоматически, но администратор доступен по электронной почте через форум.

Я посмотрел на Discourse Automation, но там такой возможности из коробки нет.

Возможно ли создать плагин, используя методы автоматизации Discourse, или его нужно писать с нуля?

Или есть более простой способ предотвратить попадание этого бесконечного спама в наш список на проверку?

Итак, я решил попробовать это и буду использовать вебхуки, которыми раньше никогда не пользовался.
Я взял за основу Use Discourse webhooks with PHP, и данные успешно возвращаются в Discourse.

Но мне нужно вручную создавать элементы для проверки спам-активности (например, «пользователь печатал слишком быстро» или «заполнил профиль, не прочитав ни одного сообщения»). Есть идеи, как это сделать?

Мне удалось заставить это работать.

Я создал пользователя через Insomnia, заполнил его профиль триггером Akismet, что вызвало создание Обзора (Review). После нескольких проверок пользователь был автоматически удалён.

Свойства Обзора, необходимые скрипту для запуска удаления пользователя:

  • Type: ReviewableAkismetUser, ReviewableUser или ReviewableQueuedPost
  • Score > 0

Я не хочу автоматически удалять пользователей, помеченных кем-либо, кроме @system.

Вот PHP-скрипт, который я использую:

<?php

// Немедленная проверка подлинности запроса.
if (array_key_exists('HTTP_X_DISCOURSE_EVENT_SIGNATURE', $_SERVER)) {
    $discourse_payload_raw = file_get_contents('php://input');
    $discourse_payload_sha256 = substr($_SERVER['HTTP_X_DISCOURSE_EVENT_SIGNATURE'], 7);
    
    // Для безопасности настройте вебхук с секретным ключом в Discourse и укажите его ниже.
    $discourse_payload_secret = '2J3tM5X4WYGkGp0tTkmu';
    
    // Проверьте, был ли запрос отправлен авторизованным вебхуком.
    if (hash_hmac('sha256', $discourse_payload_raw, $discourse_payload_secret) == $discourse_payload_sha256) {
        echo 'received';
    }
    else {
        die('authentication failed');
    }
}
else {
    die('access denied');
}

// Подготовьте payload для использования в PHP-скрипте.
$discourse_json = json_decode($discourse_payload_raw);

$reviewable = $discourse_json->reviewable;

// Настройте URL API
$api_url = "https://discourse.canapin.com/review/$reviewable->id/perform/delete_user?version=0";
//$api_url = "https://discourse.canapin.com/review/$reviewable->id/perform/delete_user?version=$reviewable->version";


// Проверьте, что свойства "type" и "score" корректны
if (($reviewable->type == "ReviewableUser" || $reviewable->type == "ReviewableAkismetUser" || $reviewable->type == "ReviewableQueuedPost") && $reviewable->score > 0) {
  // Настройте параметры curl
    $options = array(
        CURLOPT_URL => $api_url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => "PUT", // Установите метод запроса PUT
        CURLOPT_HTTPHEADER => array(
            "Api-Key: 6666666666666666666666666666666666666666666",
            "Api-Username: system"
        )
    );
    // Инициализируйте сессию curl
    $curl = curl_init();
    curl_setopt_array($curl, $options);
    // Выполните вызов API
    $response = curl_exec($curl);
    curl_close($curl);
    // Раскодировайте ответ
    $response_data = json_decode($response);
    print_r($response_data);
}   else {
    exit;
}

?>

По шкале от 0 до 10… Насколько это некрасиво надёжно, учитывая контекст, в котором оно будет работать (0 ложных срабатываний за 2 года для Discourse и обнаружений Akismet)?


У меня есть несколько вопросов относительно полезной нагрузки (payload) запроса на обзор, инициируемого Discourse, когда пользователь обнаружен как потенциальный спам-аккаунт.

  1. Почему для одного ReviewableUser отправляется 2 запроса с минимальными различиями в их соответствующих полезностях (первый запрос слева)?

  2. Что означает link_admin?

  3. Когда я вручную удаляю пользователя (обнаруженного Akismet) из панели обзора, это вызывает вебхук обзора с новым payload, содержащим, среди прочего: "user_deleted": false. Разве это не должно быть true? :thinking:

  4. В URL https://discourse.canapin.com/review/355/perform/delete_user?version=0", относится ли здесь параметр “version” к параметру “version”, найденному в payload? Должен ли я обращать на это внимание? Должен ли он быть равен параметру version из payload?

В текущем состоянии я довольно уверен, что это сработает (хотя, честно говоря, скорее интуитивно…), и мы сможем отслеживать потенциальные проблемы, анализируя результаты вебхуков…
Или просматривая список проверенных элементов.

Но есть одна проблема, которую я не могу решить.

Иногда список проверенных элементов выглядит так, без какой-либо информации:

А иногда — вот так:

Мне бы хотелось сохранять всю информацию, чтобы легче отслеживать случаи ложных срабатываний, которые были удалены.

Есть какие-нибудь идеи, откуда берётся такое поведение?

Кажется, это происходит после автоматического удаления в какой-то момент, но я не знаю, как и почему.

Добавлю, что JSON-версия страницы проверенных элементов содержит всю недостающую информацию из интерфейса Discourse.


Редактирование: Я разобрался. Это происходит, когда вы отключаете плагин Akismet.

Просто для сведения: я несколько раз видел подобное, и один раз это было ложное срабатывание — новый член сообщества, ответственный и заботливый, сначала заполнил свой профиль. Так что такое может случиться.

Да. Честно говоря, за этот период более двух лет у меня был лишь один ложноположительный результат (насколько мне известно).
Затем пользователь связался со мной по электронной почте, которую легко найти на сайте, если пользователь столкнётся с проблемой.

В моём случае, после ручной проверки тысяч пользователей, преимущество такой автоматической очистки, на мой взгляд, вполне очевидно, особенно учитывая, что это нишевый форум — пользователи, которые действительно заинтересованы в теме, обязательно свяжутся с нами, если у них возникнут какие-либо неудобства. :slight_smile: