تستخدم هذه الإضافة واجهة برمجة تطبيقات ProxyTracer لكشف وحظر حركة مرور VPN و Tor والوكلاء في Discourse.
الميزات
تمنحك تحكمًا دقيقًا في حظر مستخدمي VPN و Tor والوكلاء أثناء تسجيل مستخدمين جدد، أو مصادقة مستخدمين حاليين، أو بشكل عام لجميع زوار الموقع. إذا كنت مرتاحًا لوجود مستخدمين من VPN و Tor والوكلاء لديهم صلاحية قراءة في منتداك، فيمكنك توفير طلبات الـ API وتمكين الميزة فقط أثناء تسجيل المستخدمين والمصادقة.
تستخدم التخزين المؤقت لتخزين تقييمات عناوين IP الحديثة، مما يوفر طلبات إلى الـ API ويقلل من زمن الاستجابة. يمكنك التحكم في المدة التي يتم فيها تذكر تقييم عنوان IP من خلال الإعدادات.
في حالة حدوث مهلة زمنية للـ API أو فشل في الشبكة، تعطي الإضافة الأولوية لوصول المستخدم لمنع الحجب الواسع النطاق. يمكن تغيير هذا السلوك عبر الخيارات.
دعم مدمج لإدراج عناوين IP محددة ونطاقات CIDR في القائمة البيضاء.
انتقل إلى لوحة إدارة Discourse: Admin → Plugins → ProxyTracer للعثور على إعدادات ProxyTracer.
أدخل مفتاح الـ API الخاص بك في حقل ProxyTracer API Key.
فعّل معايير الحماية عن طريق التبديل بين Enabled during Signup، Enabled during Login و/أو Enabled for All Visitors.
أضف أي عناوين IP موثوقة أو نطاقات CIDR إلى قائمة Whitelisted IPs.
(اختياري) اضبط مهلة الـ API ووقت انتهاء صلاحية التخزين المؤقت في Redis ليتناسب مع متطلبات حركة المرور الخاصة بخادمك.
(اختياري) قم بتخصيص رسالة الحظر التي تظهر للمستخدمين المحظورين. على سبيل المثال، يمكنك إضافة تعليمات للتواصل مع إدارة الموقع في حال اعتقدوا أن الحظر غير مبرر وأنهم لا يصلون إلى الموقع عبر وكيل أو Tor أو VPN.
يعتمد الأمر على الإعدادات. يوجد إعداد في الموقع يسمح لك بتعطيل الوضع الآمن، وهو مفيد لمكون المواضيع المقيدة ومكونات/إضافات أخرى لا ينبغي للمستخدمين تعطيلها بسهولة (مثل الإعلانات، بوابة الضيوف، وما إلى ذلك). لكن في الوقت الذي تكون فيه غير مسجل الدخول، قد يجعل ذلك استخدام الوضع الآمن أكثر صعوبة للمسؤولين. أعتقد أنهم ما زالوا يستطيعون تفعيله باستخدام تسجيل الدخول كمشرف.
بالنسبة لهذه الإضافة، أشك في أن الوضع الآمن يساعد. الوضع الآمن يعطل فقط الجزء الأمامي من الإضافات، وهذه الإضافة مكتوبة بالكامل بلغة Ruby. لذا لا أعتقد أن تعطيل تخصيصات JavaScript مفيد. هذه الحقيقة تجعلني متشككًا قليلاً تجاه الإضافة، تمامًا مثل حقيقة أنها تتضمن ملف about.json وكأنها مكون سمة. لكن في النهاية، كل شخص مسؤول عن الكود الذي يثبته في منتداه.
أنت محق تمامًا في هذا، ويمكنني تأكيد ذلك من خلال اختباراتي الخاصة مع نسخة جديدة من Discourse. قمت بتحديث الوثائق فورًا لتشمل تعليمات فعّالة تتلخص في تسجيل الدخول إلى الخادم وتعطيل الإضافة يدويًا:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
يمكنني تأكيد أن الوضع الآمن غير متاح عندما تكون إعدادة “مفعلة لجميع الزوار” مفعلة، ويحاول شخص ما الدخول إلى الوضع الآمن أثناء الاتصال عبر شبكة VPN/وكيل.
في الواقع، ملف about.json غير ضروري للإضافات القياسية، لذا قمت بإزالته من المستودع.
شكرًا لك على كل ملاحظاتك @Moin. إذا كان لديك أي ملاحظات أو اقتراحات أخرى، فلا تتردد في تركها هنا. الكود مفتوح المصدر بالكامل، وأي مساهمة موضع ترحيب: GitHub - ProxyTracer/discourse-proxytracer.
أنا أختبر خدمتكم، وأودّ معرفة ما إذا كان هناك أي تعارض مع ملف ‘templates/cloudflare.template.yml’، وما إذا كان الإضافة ستدعم التحديثات المستقبلية في نواة Discourse.
شكرًا لك على الاختبار! يوصي التوثيق الموجود في ملف README.md بوضوح بشأن تكامل Cloudflare بتضمين "templates/cloudflare.template.yml"، حيث إن ذلك ضروري لضمان استخراج Discourse لعنوان IP الحقيقي للمستخدم عندما يكون المنتدى خلف Cloudflare. وبالتالي، لا يوجد تعارض مع ذلك القالب، بل إن تضمينه أمر ضروري.
ونعم، نحن ملتزمون باتباع تحديثات Discourse الأساسية لضمان التوافق الكامل مع الإصدارات الأحدث.
كنت أتساءل عما إذا كان تضمين خيار يتطلب، بدلاً من حظر المستخدمين، مجرد اجتياز اختبار hCaptcha، وجعل هذا الخيار هو الافتراضي، سيُشكّل حلًا وسطًا جيدًا، إذ إنه يضيف قدرًا كافيًا من العوائق لجعل الأمر أكثر صعوبة على المزعّمين ومن يتجنبون الحظر، في حين لا يزال يتيح للمستخدمين الشرعيين الذين يرغبون في حماية خصوصيتهم عبر الإنترنت باستخدام شبكات VPN وTor وما شابه ذلك. وبالطبع، سيظل لدى المشرفين الذين يريدون التمسك بالحظر الكامل لتلك الشبكات ذلك الخيار. ما رأيك؟
شكرًا جزيلًا! لقد أجريت للتو اختبارًا في بيئة اختبار (Sandbox) وهو يعمل بشكل مثالي.
هل تفكرون في إضافة أي ميزة متعلقة بعنوانات IP أو ASNs للشبكات المحمولة؟ مشكلة شائعة تحدث في منتدائي هي خروج المستخدم من شبكة النطاق العريض والانتقال إلى شبكة 4G/5G من مشغل الاتصالات للحصول على عنوان IP مختلف، ومحاولة بذلك التحايل على قيادات التسجيل أو تسجيل الدخول في Discourse.
سيكون من المفيد القدرة على تحديد متى كان عنوان IP ينتمي إلى ASN لمشغل محمول، وإتاحة خيار لمعالجة هذه العناوين بشكل مختلف أثناء التسجيل أو تسجيل الدخول.
ربما يكون هذا خارج نطاق ProxyTracer إلى حد ما، لأنه ليس بالضرورة مرتبطًا بالوكلاء (Proxies) أو شبكات VPN، لكنه سيكون مفيدًا لمشكلة محددة تتعلق بكيفية تعامل Discourse مع حدود الحسابات لكل عنوان IP.
في حالة hCaptcha، أنا أستخدمه بالفعل في توقيعي ويعمل بشكل جيد جداً! ربما يمكن دمج الإضافة التي يبدو أنها موجودة بالفعل في نواة Discourse مع إضافتك، أو ربما إضافة ميزة إضافية؟
أحب فكرة الإبقاء على الحظر الكامل، فهذا هو الهدف في النهاية، ولكن فيما يتعلق بعنواني IPv4 وIPv6 للشبكات الثابتة والجوال، يبدو أن جعل هذا الوصول أكثر صعوبة من خلال التحديات مفيد جداً، حيث أن الذكاء الاصطناعي يعشق إنشاء حسابات في المنتديات.
مرحبًا، شكرًا لك على أخذ ردي في الاعتبار. إنه موضوع يثير اهتمامي حقًا، وأراه تنفيذًا حساسًا بشكل خاص للجميع، سواء كنا مستخدمين أو مشرفين.
بصراحة، أشعر وكأنني روبوت يقوم بحل اختبارات CAPTCHA لإثبات أنني إنسان، وأتعمد التصرف كروبوت. لقد ذكرت في مواضيع ذات صلة أن تنفيذ Anubis (POW) يبدو أكثر راحة وفعالية بالنسبة لي.
أفهم أن هذا خارج نطاق هذا المشروع، ولكن من خلال ما يمكنني تحليله من موقعي، فإن استخدام اختبار CAPTCHA الذي ذكرته سيكون ممكنًا، ولن يحجب حرفيًا المستخدمين الذين يقدّرون خصوصيتهم ويرغبون في المساهمة دون أن يُبَقوا خارجًا.
لكي تعمل ProxyTracer بشكل فعال، يجب أن تتلقى تطبيق Discourse عنوان IP الفعلي للعميل.