نستخدم المصادقة الموحدة (SSO) لتسجيل الدخول وإنشاء الحسابات. لا توجد طريقة أخرى لتسجيل الدخول أو الاشتراك في منتدانا.
ومع ذلك، تحتوي قائمة عناوين IP المحجوبة على عشرات العناوين التي تتم إضافتها تلقائيًا يوميًا. هل هذا متوقع؟ وما الذي يجعل عنوان IP يُضاف إلى قائمة عناوين IP المحجوبة؟
الطريقة الوحيدة التي يمكنني التفكير فيها هي عند حذف حسابك واختيار زر «حذف المرسل للرسائل المزعجة».
نقطة جيدة — يتم إضافة عنوان IP إلى قائمة العناوين المحظورة (Screened IPs) فقط عند حذف حساب عبر واجهة برمجة التطبيقات (API).
ومع ذلك، نحن نرسل طلب DELETE باستخدام block_ip=false. هذا ما يظهر في سجلات Rails:
Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"}
ولكن عناوين IP يتم حظرها على أي حال، لذا ربما هناك خلل ما؟
قد يكون ذلك كذلك، رغم أنني أعتقد العكس؟ أنا أستخدم نقطة النهاية الوحيدة التي وجدتُها لـ حذف مستخدم:
DELETE /admin/users/{id}.json
والتي تحتوي بالفعل على معامل block_ip افتراضيًا على true، وأنا أعيّده دائمًا إلى false. ومع ذلك، تُضاف عناوين IP إلى عناوين IP المحجوبة على أي حال.
قد ترغب في استخدام Reverse engineer the Discourse API لرؤية الطلبات المرسلة بالضبط عند حذف مستخدم، عند الضغط على الزر الذي يقول حذف فقط
… لأنني أستطيع أن أخبرك بحزم أنه إذا كنت ترى عناوين IP تُضاف إلى قائمة الفحص بعد الحذف، فأنت بالتأكيد تحذف المستخدم كمُخرب، أي الزر الأوسط — احذف واحظر.
لقد قمت بذلك بالفعل، ونقطة نهاية واجهة برمجة التطبيقات الخاصة بالحذف هي التي كنت أستخدمها، وهي نفسها لكلتا العمليتين (الحذف فقط، والحذف مع الحظر) — الفرق الوحيد يكمن في المعاملات المستخدمة معها (block_ip، block_email، …) والتي ذكرتها أعلاه.
أعتقد أنني فهمت أخيرًا ما كانت المشكلة في طلبياتي: تطلب واجهة برمجة تطبيقات Discourse السلاسل النصية ‘true’ و’false’ بدلاً من القيم الصحيحة/الخاطئة (truthy/falsy). خطئي أنا لعدم ملاحظتي للإشارة إلى ذلك في التوثيق.
كان هذا على الأرجح ما تسبب في كل هذا الفوضى.
ربما تسرّعتُ في الكلام. 
بعد تصحيح معاملات “truthy”/“falsy” إلى سلاسل “true”/“false”، ما زلتُ أرى إدخال عناصر إلى قائمة “Screened IPs” و"Screened Emails" عند حذف المستخدمين.
إليك سجلات Rails لاستدعاء API:
Started DELETE "/admin/users/9553.json" for 123.123.123.123 at 2021-06-10 00:01:21 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"delete_posts"=>"false", "block_email"=>"false", "blocked_urls"=>"false", "block_ip"=>"false", "id"=>"9553"}
Can't verify CSRF token authenticity.
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 8ms (Views: 1.4ms | ActiveRecord: 0.0ms | Allocations: 2301)
وهذا الطلب عند تنفيذه عبر واجهة الويب بدلاً من استدعاء API:
Started DELETE "/admin/users/49.json" for 123.123.123.123 at 2021-06-10 08:24:47 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"context"=>"/admin/users/49/XXX", "delete_posts"=>"true", "id"=>"49"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 23ms (Views: 4.7ms | ActiveRecord: 0.0ms | Allocations: 1778)
إذن، بعد بعض الاختبارات، يبدو أن معاملات نقطة النهاية API /admin/users/{id}.json تُفسَّر دائمًا على أنها true عند وجودها، بغض النظر عما إذا كانت مُعيّنة فعليًا إلى ‘true’ أم ‘false’؟
عندما بدأتُ في تعيين المعاملات التي قيمتها ‘true’ فقط وتجاوز تلك التي قيمتها ‘false’، لم يعد يتم إضافة أي عناصر إلى قائمة “Screened IPs”/“Screened Emails”.
هل هذا هو السلوك المقصود؟ هذا لا يتوافق مع فهمي المستمد من التوثيق.
طالما قمت بمحاكاة السلوك الذي تلاحظه عند اتباع موضوع https://meta.discourse.org/t/how-to-reverse-engineer-the-discourse-api/20576، فستكون الأمور على ما يرام. ما هي استدعاءات واجهة برمجة التطبيقات (API) التي تلاحظها في مراقب الشبكة عند الضغط على زر “الحذف فقط”؟
في بعض الحالات، عندما لا يمرر جافا سكريبت false بوضوح إلى الخادم، يعامل الخادم أي قيمة موجودة على أنها صحيحة. وهذا على الأرجح ما تواجهه هنا.