حذف المستخدمين الذين تم وضع علامة عليهم بواسطة النظام تلقائيًا؟

[Canapin (Coin-coin le Canapin)]

مرحباً!

كل يوم، يتم الإبلاغ عن عشرات الحسابات المزعجة على أنها “أدخل هذا المستخدم الجديد معلومات الملف الشخصي دون قراءة أي مواضيع أو مشاركات”.

خلال عامين، لم يكن لدينا أي نتائج إيجابية خاطئة.

لذلك، أفكر في إمكانية حذف هذه الحسابات تلقائيًا إذا تم الإبلاغ عنها لهذا السبب المحدد.

اختياريًا، يمكن إرسال بريد إلكتروني تلقائي إلى المستلم قبل الحذف، يذكر فيه أنه تم حذف الحساب تلقائيًا، ولكن يمكن الوصول إلى المسؤول عبر البريد الإلكتروني من خلال المنتدى.

ألقيت نظرة على Discourse Automation ولكنه لا يسمح بذلك بشكل مباشر.

هل سيكون من الممكن ترميز إضافة باستخدام طرق الأتمتة في Discourse، أم يجب ترميزها من الصفر؟

أم هل هناك طريقة أسهل لمنع هذا البريد العشوائي الذي لا نهاية له من الذهاب إلى قائمة المراجعة الخاصة بنا؟

[Canapin (Coin-coin le Canapin)]

إذًا، سأجرب هذا، سأستخدم خطافات الويب التي لم أستخدمها من قبل.
لقد بدأت في استخدام Use Discourse webhooks with PHP كنموذج وهو يعيد البيانات بشكل صحيح إلى Discourse.

لكنني بحاجة إلى إنشاء عناصر مراجعة للبريد العشوائي يدويًا (مثل “قام المستخدم بالكتابة بسرعة كبيرة” أو “ملأ ملفه الشخصي دون قراءة أي منشور”). أي فكرة عن كيفية القيام بذلك؟

[Canapin (Coin-coin le Canapin)]

لقد نجحت في ذلك.

إنشاء مستخدم باستخدام Insomnia، وملء ملفه الشخصي بمشغل Akismet، مما يؤدي إلى مراجعة.
تتم إجراء بعض الفحوصات ويتم حذف المستخدم تلقائيًا.

خصائص المراجعة للنص البرمجي لتشغيل حذف المستخدم هي:

• النوع: ReviewableAkismetUser، ReviewableUser أو ReviewableQueuedPost
• النتيجة > 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);
    
    // للأمان، قم بتكوين خطاف الويب (webhook) مع سر في 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');
}

// إعداد الحمولة لاستخدامها في النص البرمجي 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";


// التحقق من أن خصائص "النوع" و "النتيجة" صالحة
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 نتائج إيجابية خاطئة في عامين لاكتشافات Discourse و akismet)؟

---

لدي بعض الأسئلة حول حمولة طلب المراجعة التي بدأتها Discourse عندما يتم اكتشاف مستخدم كحساب بريد مزعج محتمل.

1. لماذا هناك طلبان لـ 1 ReviewableUser مع اختلافات طفيفة بين حمولاتهما (الطلب الأول على اليسار)؟

   

2. ماذا يعني link_admin؟

3. عندما أقوم بحذف مستخدم يدويًا (تم اكتشافه بواسطة Akismet) من لوحة المراجعة، فإنه يؤدي إلى تشغيل خطاف الويب للمراجعة مع حمولة جديدة تحتوي، من بين أمور أخرى: "user_deleted": false. ألا ينبغي أن يكون هذا true؟

4. في عنوان URL https://discourse.canapin.com/review/355/perform/delete_user?version=0\"، هل يشير “الإصدار” هنا إلى “الإصدار” الموجود في الحمولة؟ هل يجب أن أهتم بهذا المعامل؟ هل يجب أن يكون مساويًا لمعامل version في الحمولة؟

[Canapin (Coin-coin le Canapin)]

في الوضع الحالي، أنا واثق تمامًا من أن هذا سيعمل (حسنًا، بشكل حدسي في الغالب…) ويمكننا تتبع المشكلات المحتملة من خلال النظر إلى نتائج الـ webhooks…
أو سرد العناصر التي تمت مراجعتها.

ولكن هناك مشكلة هنا لا يمكنني فهمها.

في بعض الأحيان، تبدو قائمة العناصر التي تمت مراجعتها هكذا، بدون أي معلومات:

وفي بعض الأحيان تبدو هكذا:

أود الاحتفاظ بجميع المعلومات لتتبع أي إيجابيات خاطئة تم حذفها بسهولة أكبر.

أي فكرة عن مصدر هذا السلوك؟

يبدو أنه يحدث بعد حذف تلقائي في وقت ما، لكنني لا أعرف كيف ولماذا.

أضيف أن النسخة JSON من صفحة العناصر التي تمت مراجعتها تحتوي على جميع المعلومات المفقودة من واجهة Discourse.

---

تعديل: لقد اكتشفت الأمر. هذا ما يحدث عند تعطيل إضافة Akismet.

[Ed_S]

@Canapin

كل يوم، يتم الإبلاغ عن عشرات الحسابات العشوائية على أنها “أدخل هذا المستخدم الجديد معلومات الملف الشخصي دون قراءة أي مواضيع أو مشاركات”.
في غضون عامين، لم يكن لدينا أي نتائج إيجابية خاطئة.

فقط للملاحظة، لقد رأيت هذا يظهر عددًا قليلاً من المرات، وكان مرة واحدة نتيجة إيجابية خاطئة: عضو جديد حساس ومهتم يملأ ملفه الشخصي أولاً. لذا، يمكن أن يحدث ذلك.

[Canapin (Coin-coin le Canapin)]

نعم. بصراحة، كان لدي إيجابي كاذب واحد (على حد علمي) خلال هذه الفترة التي تزيد عن عامين.
ثم تواصل معي المستخدم عبر البريد الإلكتروني، والذي يمكن العثور عليه بسهولة على الموقع إذا واجه المستخدمون مشكلة.

في حالتي، وبعد مراجعة يدوية لآلاف المستخدمين، فإن فائدة هذا الحذف التلقائي ستكون في رأيي واضحة جدًا، خاصةً وأنها منتدى متخصص - المستخدمون المهتمون حقًا بالموضوع سيتواصلون معنا إذا واجهوا أي إزعاج.