Regarding translations: My native language is English. Because this is a free and open-source hobby project which generates zero income, and translatable content is likely to change as the features and functionality supported by the project changes, it doesn't make sense for me to spend money for translations. Because I'm the sole author/developer/maintainer for the project and I'm not a ployglot, any translations I produce are very likely to contain errors. Sorry, but realistically, that won't ever change. If you find any such errors/typos/mistakes/etc, your assistance to correct them would be very much appreciated. Pull requests are invited and encouraged. Otherwise, if you find these errors too much to handle, just stick with the original English source. If a translation is irredeemably incomprehensible, let me know which, and I can delete it. If you're not sure how to perform pull requests, ask. I can help.
CIDRAM (توجيه بين المجالات لافئويا وصول مدير) هو السيناريو PHP، المصممة لحماية المواقع من طلبات الحجب تنشأ من عناوين IP تعتبر مصادر من حركة المرور غير مرغوب فيه، بما في ذلك (ولكن ليس على سبيل الحصر) حركة المرور من نقاط النهاية الوصول غير البشرية، خدمات سحابية، المتطفلين و برامج التطفل، كاشطات الموقع، إلخ. وهي تفعل ذلك عن طريق حساب CIDRs ممكن من عناوين IP الموردة من طلبات واردة وبعد ذلك محاولة لتتناسب مع هذه ضد الملفات توقيعه (هذه الملفات توقيع تحتوي CIDRs من عناوين IP تعتبر مصادر من حركة المرور غير مرغوب فيه)؛ إذا تم العثور على المباريات، يتم حظر الطلبات.
هذا البرنامج مجاني، يمكنك تعديله وإعادة نشره تحت رخصة GNU. نشارك هذا السكربت على أمل أن تعم الفائدة لكن لا نتحمل أية مسؤولية أو أية ضمانات لاستخدامك، اطلع على تفاصيل رخصة GNU للمزيد من المعلومات عبر الملف "LICENSE.txt" وللمزيد من المعلومات:
- .
- .
هذا المستند و الحزم المرتبطة به يمكن تحميلها مجاناً من:
- GitHub.
- Bitbucket.
- SourceForge.
أولاً، ستحتاج إلى نسخة حديثة من CIDRAM. يمكنك تنزيل أرشيف لأحدث إصدار من CIDRAM من المستودع CIDRAM/CIDRAM. لكي تكون محددًا، ستحتاج إلى نسخة حديثة من دليل "vault" (يمكن حذف كل شيء آخر في الأرشيف أو تجاهله بأمان).
قبل v3، كان من الضروري تثبيت CIDRAM في مكان ما داخل الجذر العام الخاص بك حتى تتمكن من الوصول إلى الواجهة الأمامية لـ CIDRAM. ومع ذلك، من v3 فصاعدًا، هذا ليس ضروريًا. من أجل تحقيق أقصى قدر من الأمان ومنع الوصول غير المصرح به إلى CIDRAM وملفاته، يوصى بدلاً من ذلك بتثبيت CIDRAM خارج جذرك العام. لا يهم مكان تثبيت CIDRAM، طالما أنه يمكن الوصول إليه في مكان ما بواسطة PHP، في مكان ما آمن بشكل معقول، وفي مكان ما تسعد به. ليس من الضروري أيضًا الاحتفاظ باسم دليل "vault" بعد الآن، لذا يمكنك إعادة تسمية "vault" إلى أي شيء تريده (ولكن من أجل الملاءمة، ستستمر الوثائق في الإشارة إلى الدليل باسم "vault").
عندما تكون جاهزًا، قم بتحميل دليل "vault" إلى الموقع الذي اخترته، وتأكد من أنه يحتوي على الأذونات اللازمة حتى تتمكن PHP من الكتابة إلى الدليل (اعتمادًا على النظام، قد لا تحتاج إلى فعل أي شيء، أو قد تحتاج إلى ضبط CHMOD 755 على الدليل، أو إذا كانت هناك مشاكل مع 755، يمكنك تجربة 777، لكن 777 غير موصى به نظرًا لكونه أقل أمانًا).
بعد ذلك، لكي تتمكن CIDRAM من حماية قاعدة التعليمات البرمجية أو CMS، ستحتاج إلى إنشاء "نقطة دخول". تتكون نقطة الدخول هذه من ثلاثة أشياء:
١. تضمين ملف "loader.php" في نقطة مناسبة في قاعدة التعليمات البرمجية أو CMS.
٢. قم بإنشاء مثيل لـ CIDRAM core.
٣. استدعاء طريقة "protect".
٢. قم بإنشاء مثيل لـ CIDRAM core.
٣. استدعاء طريقة "protect".
مثال بسيط:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\Core())->protect();إذا كنت تستخدم خادم ويب Apache ولديك حق الوصول إلى
php.ini، فيمكنك استخدام التوجيه auto_prepend_file لإرفاق CIDRAM مسبقًا كلما تم إجراء أي طلب PHP. في مثل هذه الحالة، سيكون المكان الأنسب لإنشاء نقطة الإدخال في الملف الخاص به، ويمكنك بعد ذلك الاستشهاد بهذا الملف في التوجيه auto_prepend_file.مثال:
auto_prepend_file = "/path/to/your/entrypoint.php"
أو هذا في ملف
.htaccess:php_value auto_prepend_file "/path/to/your/entrypoint.php"
في حالات أخرى، سيكون المكان الأنسب لإنشاء نقطة الدخول الخاصة بك في أقرب وقت ممكن داخل قاعدة التعليمات البرمجية أو CMS ليتم تحميلها دائمًا عندما يصل شخص ما إلى أي صفحة عبر موقع الويب بالكامل. إذا كان الكود الخاص بك يستخدم "bootstrap"، فإن المثال الجيد سيكون في بداية ملف "bootstrap" الخاص بك. إذا كانت قاعدة الشفرة الخاصة بك تحتوي على ملف مركزي مسؤول عن الاتصال بقاعدة البيانات الخاصة بك، فسيكون هناك مثال جيد آخر في بداية هذا الملف المركزي.
composer require cidram/cidram
تحذير: يؤدي تحديث CIDRAM عبر لوحة تحكم المكونات الإضافية إلى تثبيت نظيف! إذا كان لديك تخصيصات (تغيير التكوين، تثبيت وحدات، الخ)، سيتم فقدان هذه التخصيصات عند تحديث عن طريق لوحة أجهزة القياس الإضافات! كما سيتم فقدان لوغفيلز عند تحديث عن طريق لوحة أجهزة القياس الإضافات! للحفاظ على ملفات السجل والتخصيصات، يتم التحديث عبر صفحة التحديثات الأمامية ل CIDRAM.
يوصى بشدة بمراجعة تكوين التثبيت الجديد حتى تتمكن من تعديله وفقًا لاحتياجاتك. قد ترغب أيضًا في تثبيت وحدات نمطية إضافية، أو ملفات توقيع، أو إنشاء قواعد مساعدة، أو تنفيذ تخصيصات أخرى حتى يكون التثبيت الخاص بك قادرًا على تلبية احتياجاتك على أفضل وجه. أوصي باستخدام الواجهة الأمامية للقيام بهذه الأشياء.
CIDRAM يجب منع تلقائيا طلبات غير مرغوب فيها إلى موقع الويب الخاص بك، دون الحاجة إلى أي مساعدة اليدوية، جانبا من التثبيت.
يمكنك تخصيص التكوين الخاص بك وتخصيص التي CIDRs مسدودة عن طريق تعديل التكوين الخاص بك و ملفات توقيعك.
إذا واجهت أي إيجابية خاطئة، يرجى رسالة لي أن اسمحوا لي أن أعرف عن ذلك. (نرى: ما هو "إيجابية خاطئة"؟).
يمكن تحديث CIDRAM يدويا أو عن طريق الfront-end. يمكن أيضا تحديث CIDRAM عبر Composer أو WordPress، إذا تم تثبيتها أصلا عبر تلك الوسائل.
Front-end يوفر وسيلة سهلة للحفاظ على، وإدارة، وتحديث CIDRAM. يمكنك عرض، حصة، وتحميل ملفات الدخول، يمكنك تعديل تكوين، يمكنك تثبيت وإلغاء تثبيت مكونات، ويمكنك تحميل وتنزيل وتعديل الملفات.
على غرار الطريقة التي احتجت إلى إنشاء نقطة إدخال لكي يحمي CIDRAM موقع الويب الخاص بك، ستحتاج أيضًا إلى إنشاء نقطة إدخال للوصول إلى الواجهة الأمامية. تتكون نقطة الدخول هذه من ثلاثة أشياء:
١. تضمين ملف "loader.php" في نقطة مناسبة في قاعدة التعليمات البرمجية أو CMS.
٢. قم بإنشاء مثيل لـ CIDRAM front-end.
٣. استدعاء طريقة "view".
٢. قم بإنشاء مثيل لـ CIDRAM front-end.
٣. استدعاء طريقة "view".
مثال بسيط:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\FrontEnd())->view();تقوم فئة "FrontEnd" بتوسيع فئة "Core"، مما يعني أنه إذا أردت، يمكنك استدعاء طريقة "protect" قبل استدعاء طريقة "view" من أجل منع حركة المرور غير المرغوب فيها من الوصول إلى الواجهة الأمامية. القيام بذلك اختياري تمامًا.
مثال بسيط:
<?php
require_once '/path/to/the/vault/directory/loader.php';
$CIDRAM = new \CIDRAM\CIDRAM\FrontEnd();
$CIDRAM->protect();
$CIDRAM->view();المكان الأنسب لإنشاء نقطة إدخال للواجهة الأمامية هو في ملفها المخصص. على عكس نقطة الإدخال التي تم إنشاؤها مسبقًا، فأنت تريد أن يكون الوصول إلى نقطة الدخول الأمامية الخاصة بك متاحًا فقط عن طريق الطلب مباشرة للملف المحدد حيث توجد نقطة الإدخال، لذلك في هذه الحالة، لن ترغب في استخدام
auto_prepend_file أو .htaccess.بعد إنشاء نقطة الدخول الأمامية، استخدم متصفحك للوصول إليها. يجب أن يتم تقديمه مع صفحة تسجيل الدخول. في صفحة تسجيل الدخول، أدخل اسم المستخدم وكلمة المرور الافتراضيين (admin/password) واضغط على زر تسجيل الدخول.
ملحوظة: تغيير اسم المستخدم وكلمة المرور الخاصة بك بعد تسجيل الدخول للمرة الأولى، من أجل منع الوصول غير المصرح به (هذا مهم جدا)!
أيضًا، للحصول على الأمان الأمثل، نوصي بشدة بتمكين 2FA لجميع حسابات الواجهة الأمامية (الإرشادات الواردة أدناه).
في كل صفحة، ويفسر ذلك كيفية استخدامها. إذا كنت بحاجة إلى أي مساعدة، يرجى الاتصال بالدعم. وهناك أيضا بعض مقاطع الفيديو المفيدة المتاحة على موقع يوتيوب.
من الممكن جعل front-end أكثر أمانًا عن طريق تمكين 2FA. عند تسجيل الدخول إلى حساب باستخدام 2FA، يتم إرسال بريد إلكتروني إلى عنوان البريد الإلكتروني المقترن بهذا الحساب. تحتوي هذه الرسالة الإلكترونية على "رمز 2FA"، والذي يجب على المستخدم إدخاله، بالإضافة إلى اسم المستخدم وكلمة المرور، حتى تتمكن من تسجيل الدخول باستخدام هذا الحساب. وهذا يعني أن الحصول على كلمة مرور الحساب لن يكون كافيًا لأي متسلل أو مهاجم محتمل ليتمكن من تسجيل الدخول إلى هذا الحساب، لأنهم سيحتاجون أيضًا إلى الوصول بالفعل إلى عنوان البريد الإلكتروني المرتبط بهذا الحساب حتى يتمكنوا من تلقي رمز 2FA واستخدامه في الجلسة.
أولاً، لتمكين 2FA، استخدم صفحة تحديثات front-end لتثبيت مكون PHPMailer. CIDRAM يستخدم PHPMailer لإرسال رسائل البريد الإلكتروني.
بعد تثبيت PHPMailer، ستحتاج إلى تعبئة توجيهات التهيئة لـ PHPMailer عبر صفحة تهيئة CIDRAM أو ملف التكوين. يتم تضمين مزيد من المعلومات حول توجيهات التكوين هذه في قسم التكوين في هذا المستند. بعد ملء توجيهات تهيئة PHPMailer، اضبط
enable_two_factor على true. 2FA ممكّن الآن.بعد ذلك، ستحتاج إلى ربط عنوان بريد إلكتروني بحساب، حتى يعرف CIDRAM مكان إرسال رموز 2FA عند تسجيل الدخول باستخدام هذا الحساب. للقيام بذلك، استخدم عنوان البريد الإلكتروني كاسم مستخدم للحساب (مثل
foo@bar.tld)، أو تضمين عنوان البريد الإلكتروني كجزء من اسم المستخدم بالطريقة نفسها التي تريدها عند إرسال بريد إلكتروني بشكل طبيعي (مثل Foo Bar <foo@bar.tld>).ملحوظة: حماية "vault" ضد الوصول غير المصرح به (على سبيل المثال، من خلال تعزيز أمن الخادم الخاص بك وتقييد أذونات الوصول العام)، أهمية خاصة هنا، لأن الوصول غير المصرح به إلى ملف التكوين الخاص بك (المخزن في "vault")، قد يؤدي إلى تعريض إعدادات SMTP الصادرة (بما في ذلك اسم مستخدم وكلمة مرور SMTP). يجب التأكد من تأمين "vault" بشكل صحيح قبل تمكين 2FA. إذا كنت غير قادر على القيام بذلك، فعلى الأقل، يجب عليك إنشاء حساب بريد إلكتروني جديد مخصص لهذا الغرض، وذلك لتقليل المخاطر المرتبطة بإعدادات SMTP المكشوفة.
وفيما يلي قائمة من المتغيرات الموجودة في ملف تكوين "config.yml"، بالإضافة إلى وصف الغرض منه و وظيفته.
التكوين (v3)
│
├───general
│ stages [string]
│ fields [string]
│ timezone [string]
│ time_offset [int]
│ time_format [string]
│ ipaddr [string]
│ http_response_header_code [int]
│ silent_mode [string]
│ silent_mode_response_header_code [int]
│ lang [string]
│ lang_override [bool]
│ numbers [string]
│ emailaddr [string]
│ emailaddr_display_style [string]
│ ban_override [int]
│ default_dns [string]
│ default_algo [string]
│ statistics [string]
│ force_hostname_lookup [bool]
│ allow_gethostbyaddr_lookup [bool]
│ disabled_channels [string]
│ default_timeout [int]
│ sensitive [string]
│ email_notification_address [string]
│ email_notification_name [string]
├───components
│ ipv4 [string]
│ ipv6 [string]
│ modules [string]
│ imports [string]
│ events [string]
├───logging
│ standard_log [string]
│ apache_style_log [string]
│ serialised_log [string]
│ error_log [string]
│ outbound_request_log [string]
│ report_log [string]
│ truncate [string]
│ log_rotation_limit [int]
│ log_rotation_action [string]
│ log_banned_ips [bool]
│ log_sanitisation [bool]
├───frontend
│ frontend_log [string]
│ signatures_update_event_log [string]
│ max_login_attempts [int]
│ theme [string]
│ magnification [float]
│ custom_header [string]
│ custom_footer [string]
│ remotes [string]
│ enable_two_factor [bool]
├───signatures
│ shorthand [string]
│ default_tracktime [string]
│ infraction_limit [int]
│ tracking_override [bool]
├───verification
│ search_engines [string]
│ social_media [string]
│ other [string]
│ adjust [string]
├───recaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ recaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───hcaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ hcaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───legal
│ pseudonymise_ip_addresses [bool]
│ privacy_policy [string]
├───template_data
│ theme [string]
│ magnification [float]
│ css_url [string]
│ block_event_title [string]
│ captcha_title [string]
│ custom_header [string]
│ custom_footer [string]
├───rate_limiting
│ max_bandwidth [string]
│ max_requests [int]
│ precision_ipv4 [int]
│ precision_ipv6 [int]
│ allowance_period [string]
│ exceptions [string]
│ segregate [bool]
├───supplementary_cache_options
│ prefix [string]
│ enable_apcu [bool]
│ enable_memcached [bool]
│ enable_redis [bool]
│ enable_pdo [bool]
│ memcached_host [string]
│ memcached_port [int]
│ redis_host [string]
│ redis_port [int]
│ redis_timeout [float]
│ redis_database_number [int]
│ pdo_dsn [string]
│ pdo_username [string]
│ pdo_password [string]
└───bypasses
used [string]
التكوين العام (أي التكوين الأساسي لا ينتمي إلى فئات أخرى).
- ضوابط لمراحل سلسلة التنفيذ (سواء تم التمكين، أو تسجيل الأخطاء، وما إلى ذلك).
stages
├─Tests ("تنفيذ اختبارات ملفات التوقيع")
├─Modules ("تنفيذ الوحدات")
├─SearchEngineVerification ("تنفيذ التحقق من محرك البحث")
├─SocialMediaVerification ("تنفيذ التحقق من وسائل التواصل الاجتماعي")
├─OtherVerification ("تنفيذ التحقق الآخر")
├─Aux ("تنفيذ القواعد المساعدة")
├─Tracking ("تنفيذ تتبع IP")
├─RL ("تنفيذ تحديد معدل")
├─CAPTCHA ("انشر الكابتشا (الطلبات المحظورة)")
├─Reporting ("تنفيذ التقارير")
├─Statistics ("تحديث الإحصائيات")
├─Webhooks ("تنفيذ الخطافات على الويب")
├─PrepareFields ("تحضير الحقول للإخراج والسجلات")
├─Output ("توليد الإخراج (الطلبات المحظورة)")
├─WriteLogs ("الكتابة إلى السجلات (الطلبات المحظورة)")
├─Terminate ("قم بإنهاء الطلب (الطلبات المحظورة)")
├─AuxRedirect ("إعادة التوجيه وفقًا للقواعد المساعدة")
└─NonBlockedCAPTCHA ("انشر الكابتشا (الطلبات غير المحظورة)")
- ضوابط الحقول أثناء أحداث الكتلة (عندما يتم حظر طلب).
fields
├─ID ("الهوية الشخصية")
├─ScriptIdent ("النسخة النصية")
├─DateTime ("الوقت/التاريخ")
├─IPAddr ("عنوان IP")
├─IPAddrResolved ("عنوان IP (تم حلها)")
├─Query ("إستعلام")
├─Referrer ("المرجع")
├─UA ("وكيل المستخدم")
├─UALC ("وكيل المستخدم (أحرف صغيرة)")
├─SignatureCount ("عدد التوقيعات")
├─Signatures ("مرجع التوقيعات")
├─WhyReason ("سبب الحظر")
├─ReasonMessage ("سبب الحظر (مفصلة)")
├─rURI ("أعيد بناؤها URI")
├─Infractions ("مخالفات")
├─ASNLookup ("** بحث ASN")
├─CCLookup ("** بحث عن كود البلد")
├─Verified ("التحقق من الهوية")
├─Expired ("منتهية الصلاحية")
├─Ignored ("تجاهل")
├─Request_Method ("Request method")
├─Protocol ("بروتوكول")
├─SEC_CH_UA_PLATFORM ("!! SEC_CH_UA_PLATFORM")
├─SEC_CH_UA_MOBILE ("!! SEC_CH_UA_MOBILE")
├─SEC_CH_UA ("!! SEC_CH_UA")
├─Hostname ("اسم المضيف")
├─CAPTCHA ("الحالة CAPTCHA")
├─Inspection ("* فحص الشروط")
└─ClientL10NAccepted ("تم حل اللغة")
- مخصص فقط من أجل تصحيح أخطاء القواعد المساعدة. غير معروض أمام المستخدمين المحظورين.
** يتطلب وظيفة بحث ASN (على سبيل المثال، عبر وحدة IP-API أو وحدة BGPView).
!! هذا تلميح عميل منخفض الإنتروبيا. تلميحات العميل بمثابة تقنية ويب تجريبية جديدة، وهي غير مدعومة على نطاق واسع حتى الآن عبر جميع المتصفحات والعملاء الرئيسيين. يرى: Sec-CH-UA - HTTP | MDN. يمكن أن تكون تلميحات العميل مفيدة في أخذ البصمات، ولكن بما أنها غير مدعومة على نطاق واسع، فلا ينبغي افتراض وجودها في الطلبات أو الاعتماد عليها (أي أن، الحظر بناءً على غيابهم فكرة سيئة).
- يتم استخدام هذا لتحديد المنطقة الزمنية للاستخدام (على سبيل المثال، Africa/Cairo، America/New_York، Asia/Tokyo، Australia/Perth، Europe/Berlin، Pacific/Guam، إلخ). حدد "SYSTEM" للسماح لـ PHP بمعالجة هذا الأمر تلقائيًا.
timezone
├─SYSTEM ("استخدام المنطقة الزمنية الافتراضية للنظام.")
├─UTC ("UTC")
└─…آخر
- المنطقة الزمنية تعويض في غضون دقائق.
- شكل التواريخ المستخدم من قبل CIDRAM. ويمكن إضافة خيارات إضافية عند الطلب.
time_format
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz}")
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss}")
├─{Day}, {dd} {Mon} {yyyy} ("{Day}, {dd} {Mon} {yyyy}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yyyy}.{mm}.{dd} ("{yyyy}.{mm}.{dd}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yyyy}-{mm}-{dd} ("{yyyy}-{mm}-{dd}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yyyy}/{mm}/{dd} ("{yyyy}/{mm}/{dd}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yyyy} ("{dd}.{mm}.{yyyy}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yyyy} ("{dd}-{mm}-{yyyy}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yyyy} ("{dd}/{mm}/{yyyy}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yyyy} ("{mm}.{dd}.{yyyy}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yyyy} ("{mm}-{dd}-{yyyy}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yyyy} ("{mm}/{dd}/{yyyy}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yy}.{mm}.{dd} ("{yy}.{mm}.{dd}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yy}-{mm}-{dd} ("{yy}-{mm}-{dd}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yy}/{mm}/{dd} ("{yy}/{mm}/{dd}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yy} ("{dd}.{mm}.{yy}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yy} ("{dd}-{mm}-{yy}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yy} ("{dd}/{mm}/{yy}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yy} ("{mm}.{dd}.{yy}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yy} ("{mm}-{dd}-{yy}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yy} ("{mm}/{dd}/{yy}")
├─{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yyyy}年{m}月{d}日 ("{yyyy}年{m}月{d}日")
├─{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yy}年{m}月{d}日 ("{yy}年{m}月{d}日")
├─{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yyyy}년 {m}월 {d}일 ("{yyyy}년 {m}월 {d}일")
├─{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yy}년 {m}월 {d}일 ("{yy}년 {m}월 {d}일")
├─{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z} ("{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z}")
├─{d}. {m}. {yyyy} ("{d}. {m}. {yyyy}")
└─…آخر
العنصر النائب – تفسير – مثال يعتمد على 2024-04-30T18:27:49+08:00.
{yyyy} – السنة – على سبيل المثال، 2024.
{yy} – السنة المختصرة – على سبيل المثال، 24.
{Mon} – اسم الشهر المختصر (باللغة الإنجليزية) – على سبيل المثال، Apr.
{mm} – الشهر الذي مع الأصفار البادئة – على سبيل المثال، 04.
{m} – الشهر – على سبيل المثال، 4.
{Day} – اسم اليوم المختصر (باللغة الإنجليزية) – على سبيل المثال، Tue.
{dd} – اليوم مع الأصفار البادئة – على سبيل المثال، 30.
{d} – اليوم – على سبيل المثال، 30.
{hh} – الساعة مع الأصفار البادئة (تستخدم نظام 24 ساعة) – على سبيل المثال، 18.
{h} – الساعة (تستخدم نظام 24 ساعة) – على سبيل المثال، 18.
{ii} – الدقيقة مع الأصفار البادئة – على سبيل المثال، 27.
{i} – الدقيقة – على سبيل المثال، 27.
{ss} – الثواني مع الأصفار البادئة – على سبيل المثال، 49.
{s} – الثواني – على سبيل المثال، 49.
{tz} – المنطقة الزمنية (بدون النقطتين) – على سبيل المثال، +0800.
{t:z} – المنطقة الزمنية (مع النقطتين) – على سبيل المثال، +08:00.
- أين يمكن العثور على عنوان IP لربط الطلبات؟ (مفيدة للخدمات مثل لايتكلاود و مثلها). الافتراضي = REMOTE_ADDR. تحذير: لا تغير هذا إلا إذا كنت تعرف ما تفعلونه!
ipaddr
├─HTTP_INCAP_CLIENT_IP ("HTTP_INCAP_CLIENT_IP (Incapsula)")
├─HTTP_CF_CONNECTING_IP ("HTTP_CF_CONNECTING_IP (Cloudflare)")
├─CF-Connecting-IP ("CF-Connecting-IP (Cloudflare)")
├─HTTP_X_FORWARDED_FOR ("HTTP_X_FORWARDED_FOR (Cloudbric)")
├─X-Forwarded-For ("X-Forwarded-For (Squid)")
├─Forwarded ("Forwarded")
├─REMOTE_ADDR ("REMOTE_ADDR (الافتراضي)")
└─…آخر
- ما هي رسالة حالة HTTP التي يجب أن يرسلها CIDRAM عند حظر الطلبات؟
http_response_header_code
├─200 (200 OK (حسنا)): أقل قوة، ولكن الأكثر سهولة في الاستخدام.
│ من المرجح أن تفسر الطلبات الآلية هذه
│ الاستجابة على أنها إشارة إلى نجاح الطلب.
├─403 (403 Forbidden (مُحرَّم)): أكثر قوة، ولكن أقل سهولة في الاستخدام.
│ موصى به لمعظم الظروف العامة.
├─410 (410 Gone (ذهب)): يمكن أن يسبب مشاكل عند حل الإيجابيات
│ الخاطئة، لأن بعض المتصفحات سوف تخزن رسالة
│ الحالة هذه مؤقتًا ولا ترسل طلبات لاحقة،
│ حتى بعد إلغاء الحظر. قد يكون الأكثر
│ تفضيلاً في بعض السياقات، لأنواع معينة من
│ حركة المرور.
├─418 (418 I'm a teapot (أنا إبريق شاي)): يشير إلى نكتة كذبة أبريل (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). من غير المحتمل
│ جدًا أن يفهمه أي عميل أو روبوت أو متصفح أو
│ غير ذلك. يتم توفيرها للتسلية والراحة،
│ ولكن لا يوصى بها بشكل عام.
├─451 (451 Unavailable For Legal Reasons (غير متاح لأسباب قانونية)): يوصى به عند الحظر لأسباب قانونية في
│ المقام الأول. لا ينصح به في سياقات أخرى.
└─503 (503 Service Unavailable (الخدمة غير متوفرة)): الأكثر قوة، ولكن الأقل سهولة في
الاستخدام. يوصى به عند التعرض للهجوم أو
عند التعامل مع حركة مرور غير مرغوب فيها
بشكل دائم للغاية.
- يجب CIDRAM إعادة توجيه بصمت محاولات وصول مرفوض بدلا من عرض الصفحة "تم رفض الوصول"؟ اذا نعم، تحديد الموقع لإعادة توجيه محاولات وصول مرفوض. ان لم، ترك هذا الحقل فارغا.
- ما رسالة حالة HTTP التي يجب على CIDRAM إرسالها عند إعادة توجيه محاولات الوصول المحظورة بصمت؟
silent_mode_response_header_code
├─301 (301 Moved Permanently (منقول بشكل دائم)): يوجه العميل أن إعادة التوجيه دائمة، وأن
│ طريقة الطلب المستخدمة لإعادة التوجيه قد
│ تكون مختلفة عن طريقة الطلب المستخدمة
│ للطلب الأولي.
├─302 (302 Found (موجود)): يوجه العميل أن إعادة التوجيه مؤقتة، وأن
│ طريقة الطلب المستخدمة لإعادة التوجيه قد
│ تكون مختلفة عن طريقة الطلب المستخدمة
│ للطلب الأولي.
├─307 (307 Temporary Redirect (إعادة توجيه مؤقتة)): يوجه العميل أن إعادة التوجيه مؤقتة، وأن
│ طريقة الطلب المستخدمة لإعادة التوجيه قد
│ لا تختلف عن طريقة الطلب المستخدمة للطلب
│ الأولي.
└─308 (308 Permanent Redirect (إعادة توجيه دائمة)): يوجه العميل أن إعادة التوجيه دائمة، وأن
طريقة الطلب المستخدمة لإعادة التوجيه قد
لا تختلف عن طريقة الطلب المستخدمة للطلب
الأولي.
بغض النظر عن الطريقة التي نوجه بها للعميل، من المهم أن نتذكر أننا في النهاية ليس لدينا أي سيطرة على ما يختاره العميل، وليس هناك ما يضمن أن العميل سوف يحترم تعليماتنا.
- تحديد اللغة الافتراضية الخاصة بـ CIDRAM.
lang
├─af ("Afrikaans")
├─ar ("العربية")
├─bg ("Български")
├─bn ("বাংলা")
├─bs ("Bosanski")
├─ca ("Català")
├─cs ("Čeština")
├─de ("Deutsch")
├─en ("English (AU/GB/NZ)")
├─en-CA ("English (CA)")
├─en-US ("English (US)")
├─es ("Español")
├─fa ("فارسی")
├─fr ("Français")
├─gl ("Galego")
├─gu ("ગુજરાતી")
├─he ("עברית")
├─hi ("हिंदी")
├─hr ("Hrvatski")
├─id ("Bahasa Indonesia")
├─it ("Italiano")
├─ja ("日本語")
├─ko ("한국어")
├─lv ("Latviešu")
├─ms ("Bahasa Melayu")
├─nl ("Nederlandse")
├─no ("Norsk")
├─pa ("ਪੰਜਾਬੀ")
├─pl ("Polski")
├─pt-BR ("Português (Brasil)")
├─pt-PT ("Português (Europeu)")
├─ro ("Română")
├─ru ("Русский")
├─sv ("Svenska")
├─sr ("Српски")
├─ta ("தமிழ்")
├─th ("ภาษาไทย")
├─tr ("Türkçe")
├─uk ("Українська")
├─ur ("اردو")
├─vi ("Tiếng Việt")
├─zh-Hans ("中文（简体）")
└─zh-Hant ("中文（傳統）")
- الترجمة وفقًا لـ HTTP_ACCEPT_LANGUAGE كلما أمكن ذلك؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- كيف تفضل الأرقام ليتم عرضها؟ حدد المثال الذي يبدو أكثر صحيح لك.
numbers
├─Arabic-1 ("١٢٣٤٥٦٧٫٨٩")
├─Arabic-2 ("١٬٢٣٤٬٥٦٧٫٨٩")
├─Arabic-3 ("۱٬۲۳۴٬۵۶۷٫۸۹")
├─Arabic-4 ("۱۲٬۳۴٬۵۶۷٫۸۹")
├─Armenian ("Ճ̅Ի̅Գ̅ՏՇԿԷ")
├─Base-12 ("4b6547.a8")
├─Base-16 ("12d687.e3")
├─Bengali-1 ("১২,৩৪,৫৬৭.৮৯")
├─Burmese-1 ("၁၂၃၄၅၆၇.၈၉")
├─China-1 ("123,4567.89")
├─Chinese-Simplified ("一百二十三万四千五百六十七点八九")
├─Chinese-Simplified-Financial ("壹佰贰拾叁萬肆仟伍佰陆拾柒点捌玖")
├─Chinese-Traditional ("一百二十三萬四千五百六十七點八九")
├─Chinese-Traditional-Financial ("壹佰貳拾叄萬肆仟伍佰陸拾柒點捌玖")
├─Fullwidth ("１２３４５６７.８９")
├─Geez ("፻፳፫፼፵፭፻፷፯")
├─Hebrew ("א׳׳ב׳קג׳יד׳ךסז")
├─India-1 ("12,34,567.89")
├─India-2 ("१२,३४,५६७.८९")
├─India-3 ("૧૨,૩૪,૫૬૭.૮૯")
├─India-4 ("੧੨,੩੪,੫੬੭.੮੯")
├─India-5 ("೧೨,೩೪,೫೬೭.೮೯")
├─India-6 ("౧౨,౩౪,౫౬౭.౮౯")
├─Japanese ("百万二十万三万四千五百六十七・八九分")
├─Javanese ("꧑꧒꧓꧔꧕꧖꧗.꧘꧙")
├─Khmer-1 ("១.២៣៤.៥៦៧,៨៩")
├─Lao-1 ("໑໒໓໔໕໖໗.໘໙")
├─Latin-1 ("1,234,567.89")
├─Latin-2 ("1 234 567.89")
├─Latin-3 ("1.234.567,89")
├─Latin-4 ("1 234 567,89")
├─Latin-5 ("1,234,567·89")
├─Mayan ("𝋧𝋮𝋦𝋨𝋧.𝋱𝋰")
├─Mongolian ("᠑᠒᠓᠔᠕᠖᠗.᠘᠙")
├─NoSep-1 ("1234567.89")
├─NoSep-2 ("1234567,89")
├─Odia ("୧୨୩୪୫୬୭.୮୯")
├─Roman ("M̅C̅C̅X̅X̅X̅I̅V̅DLXVII")
├─SDN-Dwiggins ("4E6,547;X8")
├─SDN-Pitman ("4↋6,547;↊8")
├─Tamil ("௲௲௨௱௲௩௰௲௪௲௫௱௬௰௭")
├─Thai-1 ("๑,๒๓๔,๕๖๗.๘๙")
├─Thai-2 ("๑๒๓๔๕๖๗.๘๙")
└─Tibetan ("༡༢༣༤༥༦༧.༨༩")
- لو كنت تريد، يمكنك توفير عنوان البريد الإلكتروني هنا أن تعطى للمستخدمين عند أنها ممنوعة، بالنسبة لهم لاستخدامها كنقطة اتصال للحصول على الدعم والمساعدة لفي حال منهم سدت طريق الخطأ أو في ضلال. تحذير: أي عنوان البريد الإلكتروني الذي تزويد هنا وبالتأكيد سيتم شراؤها من قبل المتطفلين و برامج التطفل وكاشطات خلال المستخدمة هنا، و حينئذ، انها المستحسن أن إذا اخترت توفير عنوان البريد الإلكتروني هنا، يمكنك التأكد من أن عنوان البريد الإلكتروني الذي نورد هنا يمكن التخلص منها و/أو عنوان أنك لا تمانع في أن محتوى غير مرغوب فيه (بعبارات أخرى، وربما كنت لا تريد استخدام الرئيسية عناوين البريد الإلكتروني التجارية أو العناوين الشخصية الرئيسية الخاصة بك).
- كيف تفضل أن يتم تقديم عنوان البريد الإلكتروني إلى المستخدمين؟
emailaddr_display_style
├─default ("رابط قابل للنقر")
└─noclick ("نص غير قابل للنقر")
- تجاوز "http_response_header_code" متى "infraction_limit" تجاوزت؟ 200 = لا تجاوز [الافتراضي]. القيم الأخرى هي نفس القيم المتاحة لـ "http_response_header_code".
ban_override
├─200 (200 OK (حسنا)): أقل قوة، ولكن الأكثر سهولة في الاستخدام.
│ من المرجح أن تفسر الطلبات الآلية هذه
│ الاستجابة على أنها إشارة إلى نجاح الطلب.
├─403 (403 Forbidden (مُحرَّم)): أكثر قوة، ولكن أقل سهولة في الاستخدام.
│ موصى به لمعظم الظروف العامة.
├─410 (410 Gone (ذهب)): يمكن أن يسبب مشاكل عند حل الإيجابيات
│ الخاطئة، لأن بعض المتصفحات سوف تخزن رسالة
│ الحالة هذه مؤقتًا ولا ترسل طلبات لاحقة،
│ حتى بعد إلغاء الحظر. قد يكون الأكثر
│ تفضيلاً في بعض السياقات، لأنواع معينة من
│ حركة المرور.
├─418 (418 I'm a teapot (أنا إبريق شاي)): يشير إلى نكتة كذبة أبريل (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). من غير المحتمل
│ جدًا أن يفهمه أي عميل أو روبوت أو متصفح أو
│ غير ذلك. يتم توفيرها للتسلية والراحة،
│ ولكن لا يوصى بها بشكل عام.
├─451 (451 Unavailable For Legal Reasons (غير متاح لأسباب قانونية)): يوصى به عند الحظر لأسباب قانونية في
│ المقام الأول. لا ينصح به في سياقات أخرى.
└─503 (503 Service Unavailable (الخدمة غير متوفرة)): الأكثر قوة، ولكن الأقل سهولة في
الاستخدام. يوصى به عند التعرض للهجوم أو
عند التعامل مع حركة مرور غير مرغوب فيها
بشكل دائم للغاية.
- قائمة من خوادم DNS لاستخدامها في عمليات البحث عن اسم المضيف. تحذير: لا تغير هذا إلا إذا كنت تعرف ما تفعلونه!
FAQ. ما الذي يمكنني استخدامه لـ "default_dns"؟
- يحدد الخوارزمية التي سيتم استخدامها لكل كلمات المرور والجلسات المستقبلية.
default_algo
├─PASSWORD_DEFAULT ("PASSWORD_DEFAULT")
├─PASSWORD_BCRYPT ("PASSWORD_BCRYPT")
├─PASSWORD_ARGON2I ("PASSWORD_ARGON2I")
└─PASSWORD_ARGON2ID ("PASSWORD_ARGON2ID (PHP >= 7.3.0)")
- يتحكم في المعلومات الإحصائية التي يجب تتبعها.
statistics
├─Blocked-IPv4 ("الطلبات المحظورة – IPv4")
├─Blocked-IPv6 ("الطلبات المحظورة – IPv6")
├─Blocked-Other ("الطلبات المحظورة – آخر")
├─Banned-IPv4 ("طلبات محظورة – IPv4")
├─Banned-IPv6 ("طلبات محظورة – IPv6")
├─Passed-IPv4 ("مرت الطلبات – IPv4")
├─Passed-IPv6 ("مرت الطلبات – IPv6")
├─Passed-Other ("مرت الطلبات – آخر")
├─CAPTCHAs-Failed ("محاولات CAPTCHA – فشل!")
├─CAPTCHAs-Passed ("محاولات CAPTCHA – نجحت!")
├─Reported-IPv4-OK ("تم الإبلاغ عن الطلبات إلى API الخارجية – IPv4 – حسنا")
├─Reported-IPv4-Failed ("تم الإبلاغ عن الطلبات إلى API الخارجية – IPv4 – فشل")
├─Reported-IPv6-OK ("تم الإبلاغ عن الطلبات إلى API الخارجية – IPv6 – حسنا")
└─Reported-IPv6-Failed ("تم الإبلاغ عن الطلبات إلى API الخارجية – IPv6 – فشل")
ملاحظة: يمكن التحكم في تتبع الإحصائيات للقواعد المساعدة من صفحة القواعد المساعدة.
- فرض بحث اسم المضيف؟ صحيح/True = نعم؛ زائفة/False = لا [افتراضي]. يتم إجراء عمليات البحث عن اسم المضيف عادة على أساس "حسب الحاجة"، ولكن يمكن إجبارها على جميع الطلبات. وقد يكون القيام بذلك مفيدا كوسيلة لتوفير معلومات أكثر تفصيلا في السجلات، ولكن قد يكون له أيضا أثر سلبي طفيف على الأداء.
- السماح بعمليات البحث gethostbyaddr عندما يكون UDP غير متوفر؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
ملاحظة: قد لا تعمل عمليات بحث IPv6 بشكل صحيح على بعض أنظمة 32 بت.
- يمكن استخدام هذا لمنع CIDRAM من استخدام قنوات معينة عند إرسال الطلبات (على سبيل المثال، عند التحديث، عند جلب بيانات تعريف المكون، إلخ).
disabled_channels
├─GitHub ("GitHub")
├─BitBucket ("BitBucket")
└─GoogleDNS ("GoogleDNS")
- المهلة الافتراضية لاستخدامها للطلبات الخارجية؟ الافتراضي = 12 ثانية.
- قائمة المسارات التي يجب اعتبارها صفحات حساسة. ستتم مقارنة كل مسار مدرج مع URI المعاد بناؤه عند الحاجة. سيتم التعامل مع المسار الذي يبدأ بشرطة مائلة للأمام على أنه حرفي، ويتم مطابقته من مكون المسار للطلب فصاعدًا. سيتم التعامل مع المسار الذي يبدأ بحرف غير أبجدي رقمي وينتهي بنفس الحرف (أو نفس الحرف بالإضافة إلى علامة اختيارية "i") كتعبير عادي. سيتم التعامل مع أي نوع آخر من المسارات على أنه حرفي، ويمكن أن يتطابق مع أي جزء من URI. قد يؤثر المسار الذي يتم اعتباره صفحة حساسة على كيفية تصرف بعض الوحدات، ولكن ليس له أي تأثير آخر.
- إذا اخترت تلقي الإشعارات من CIDRAM عبر البريد الإلكتروني، على سبيل المثال، عند تفعيل قواعد مساعدة محددة، يمكنك تحديد عنوان المستلم لهذه الإشعارات هنا.
- إذا اخترت تلقي الإشعارات من CIDRAM عبر البريد الإلكتروني، على سبيل المثال، عند تفعيل قواعد مساعدة محددة، يمكنك تحديد اسم المستلم لتلك الإشعارات هنا.
التكوين لتنشيط وتعطيل المكونات المستخدمة من قبل CIDRAM. عادةً ما يتم ملؤها بواسطة صفحة التحديثات، ولكن يمكن أيضًا إدارتها من هنا لتحكم أفضل وللمكونات المخصصة التي لا تتعرف عليها صفحة التحديثات.
- ملفات توقيع IPv4.
- ملفات توقيع IPv6.
- الوحدات.
- الواردات. تُستخدم عادةً لتزويد معلومات تكوين المكون إلى CIDRAM.
- معالجات الأحداث. تُستخدم عادةً لتعديل الطريقة التي يتصرف بها CIDRAM داخليًا أو لتوفير وظائف إضافية.
التكوين المتعلق بالتسجيل (باستثناء ما ينطبق على الفئات الأخرى).
- ملف يمكن قراءته بالعين لتسجيل كل محاولات الوصول سدت. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف على غرار أباتشي لتسجيل كل محاولات الوصول سدت. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف تسلسل لتسجيل كل محاولات الوصول سدت. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف لتسجيل أي أخطاء غير مميتة المكتشفة. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف لتسجيل نتائج أي طلبات صادرة. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف لتسجيل أي تقارير يتم إرسالها إلى واجهات برمجة التطبيقات الخارجية. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- اقتطاع ملفات السجل عندما تصل إلى حجم معين؟ القيمة هي الحجم الأقصى في بايت/كيلوبايت/ميغابايت/غيغابايت/تيرابايت الذي قد ينمو ملفات السجل إلى قبل اقتطاعه. القيمة الافتراضية 0KB تعطيل اقتطاع (ملفات السجل يمكن أن تنمو إلى أجل غير مسمى). ملاحظة: ينطبق على ملفات السجل الفردية! ولا يعتبر حجمها جماعيا.
- يحدد تدوير السجل عدد ملفات السجل التي يجب أن تكون موجودة في أي وقت. عند إنشاء ملفات السجل الجديدة، إذا تجاوز العدد الإجمالي لبيانات السجل الحد المحدد، فسيتم تنفيذ الإجراء المحدد. يمكنك تحديد الحد المرغوب هنا. ستعمل القيمة 0 على تعطيل تدوير السجل.
- يحدد تدوير السجل عدد ملفات السجل التي يجب أن تكون موجودة في أي وقت. عند إنشاء ملفات السجل الجديدة، إذا تجاوز العدد الإجمالي لبيانات السجل الحد المحدد، فسيتم تنفيذ الإجراء المحدد. يمكنك تحديد الإجراء المطلوب هنا.
log_rotation_action
├─Delete ("احذف أقدم السجلات، حتى لا يتم تجاوز الحد.")
└─Archive ("أرشفة أولاً، ثم احذف أقدم السجلات، حتى لا يتم تجاوز الحد.")
- من IP المحظورة في ملفات السجل؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- عند استخدام صفحة سجلات الواجهة الأمامية لعرض بيانات السجل، تقوم CIDRAM بتعقيم بيانات السجل قبل عرضها، لحماية المستخدمين من هجمات XSS والتهديدات المحتملة الأخرى التي قد تحتوي عليها بيانات السجل. ومع ذلك، بشكل افتراضي، لا يتم تعقيم البيانات أثناء التسجيل. هذا لضمان الحفاظ على بيانات السجل بدقة، للمساعدة في أي تحليل شرعي قد يكون ضروريًا في المستقبل. ومع ذلك، في حالة محاولة المستخدم قراءة بيانات السجل باستخدام أدوات خارجية، وإذا لم تقم تلك الأدوات الخارجية بعملية الصرف الصحي الخاصة بها، فقد يتعرض المستخدم لهجمات XSS. إذا لزم الأمر، يمكنك تغيير السلوك الافتراضي باستخدام توجيه التكوين هذا. True = قم بتعقيم البيانات عند تسجيلها (يتم الاحتفاظ بالبيانات بدقة أقل، لكن خطر XSS أقل). False = لا تقم بتعقيم البيانات عند تسجيلها (يتم الاحتفاظ البيانات بشكل أكثر دقة، ولكن خطر XSS أعلى) [افتراضي].
التكوين للواجهة الأمامية.
- ملف لتسجيل محاولات الدخول الأمامية. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- ملف للتسجيل عند تحديث التوقيعات عبر الواجهة الأمامية. تحديد اسم الملف، أو اتركه فارغا لتعطيل.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- الحد الأقصى لعدد محاولات تسجيل الدخول (front-end). الافتراضي = 5.
- الموضوع الافتراضي الذي سيتم استخدامه للواجهة الأمامية.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…آخر
- تكبير الخط. افتراضي = 1.
- تم إدراجها بتنسيق HTML في بداية جميع الصفحات الأمامية. قد يكون هذا مفيدًا في حالة رغبتك في تضمين شعار موقع ويب أو رأس مخصص أو نصوص أو ما شابه ذلك في جميع هذه الصفحات.
- تم إدراجها بتنسيق HTML في الجزء السفلي من جميع الصفحات الأمامية. قد يكون هذا مفيدًا في حالة رغبتك في تضمين إشعار قانوني أو رابط اتصال أو معلومات تجارية أو ما شابه ذلك في كل هذه الصفحات.
- قائمة بالعناوين التي يستخدمها المُحدِّث لجلب البيانات الوصفية للمكون. قد يحتاج هذا إلى تعديل عند الترقية إلى إصدار رئيسي جديد، أو عند الحصول على مصدر جديد للتحديثات، ولكن في ظل الظروف العادية يجب تركه بمفرده.
- يحدد هذا التوجيه ما إذا كان سيتم استخدام 2FA للحسابات front-end أم لا.
التكوين للتوقيعات، ملفات التوقيع، الوحدات النمطية، إلخ.
- ضوابط لما يجب فعله بالطلب عندما يكون هناك تطابق إيجابي مع توقيع يستخدم كلمات قصيرة المحددة.
shorthand
├─Attacks ("هجمات")
├─Bogon ("⁰ المريخ IP")
├─Cloud ("الخدمات السحابية")
├─Generic ("عام")
├─Legal ("¹ قانوني")
├─Malware ("البرمجيات الخبيثة")
├─Proxy ("² خدمة بروكسي")
├─Spam ("خطر البريد المزعج")
├─Banned ("³ حظر")
├─BadIP ("³ IP غير صالح")
├─RL ("³ معدل محدود")
└─Other ("⁴ آخر")
0. إذا كان موقع الويب الخاص بك يحتاج إلى الوصول عبر LAN أو localhost، فلا منعه. إذا لم تكن هناك حاجة، يمكنك منعه.
1. ملفات التوقيع القياسية لا تستخدم هذا، لكنه يظل مدعومًا في حالة ما إذا كان مفيدًا لبعض المستخدمين.
2. إذا كنت تريد أن يتمكن المستخدمون من الوصول إلى موقع الويب الخاص بك عبر الوكلاء، فلا منعه. إذا لم تكن هناك حاجة، يمكنك منعه.
3. لا يتم دعم الاستخدام المباشر داخل التواقيع، ولكن قد يتم استدعاؤه بوسائل أخرى في ظروف معينة.
4. الحالات التي لا تستخدم فيها الكلمات القصيرة، أو لا يتعرف عليها CIDRAM.
واحد لكل توقيع. قد يستدعي التوقيع عدة ملفات تعريف، لكن يمكنه استخدام كلمة قصيرة واحدة فقط. قد تكون الكلمات القصيرة المتعددة مناسبة، ولكن يمكن استخدام كلمة واحدة فقط، لذلك نحاول دائمًا استخدام الأنسب فقط.
أولوية. دائمًا ما يكون للخيار المحدد الأولوية على الخيار غير المحدد. على سبيل المثال، إذا كانت هناك عدة كلمات القصيرة سارية المفعول ولكن تم تعيين كلمة واحدة فقط على أنها محظورة، فسيظل الطلب محظورًا.
نقاط النهاية البشرية والخدمات السحابية. قد تشير الخدمة السحابية إلى موفري خدمات الاستضافة على الويب، أو مزارع الخوادم، أو مراكز البيانات، أو عدد من الأشياء الأخرى. تشير نقطة النهاية البشرية إلى الوسائل التي يصل بها الإنسان إلى الإنترنت، على سبيل المثال عن طريق مزود خدمة الإنترنت. عادةً ما توفر الشبكة واحدًا أو الآخر فقط، ولكنها قد توفر الاثنين معًا في بعض الأحيان. نحن نحاول عدم تحديد نقاط النهاية البشرية المحتملة على أنها خدمات سحابية. لذلك، يمكن تعريف الخدمة السحابية على أنها شيء آخر إذا كان نطاقها مشتركًا بواسطة نقاط نهاية بشرية معروفة. وبالمثل، نحاول دائمًا تحديد الخدمات السحابية، التي لا تتم مشاركة نطاقاتها بواسطة أي نقاط نهاية بشرية معروفة، على أنها خدمات سحابية. لذلك، فإن الطلب الذي تم تحديده على أنه خدمة سحابية على الأرجح لا يشارك نطاقه مع أي نقاط نهاية بشرية معروفة. وبالمثل، فإن الطلب الذي تم تحديده صراحةً من خلال الهجمات أو البريد العشوائي على الأرجح يقوم بمشاركتها. ومع ذلك، فإن الإنترنت دائمًا في حالة تغير مستمر، وتتغير أغراض الشبكات بمرور الوقت، ويتم دائمًا شراء أو بيعها النطاقات، لذلك كن مدركًا ويقظًا فيما يتعلق بالإيجابيات الخاطئة.
- المدة التي يجب أن يتم تتبع عناوين IP لها. افتراضي = 7d0°0′0″ (1 أسبوع).
- يسمح الحد الأقصى لعدد المخالفات IP يمكن أن تتكبد قبل أن يتم حظره من قبل تتبع IP. افتراضي = 10.
- هل تسمح للوحدات النمطية بتجاوز خيارات التتبع؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
التكوين للتحقق من مصدر الطلبات.
- آلية الرقابة للتحقق من الطلبات الواردة من محركات البحث.
search_engines
├─Amazonbot ("Amazonbot")
├─Applebot ("Applebot")
├─Baidu ("* Baiduspider/百度")
├─Bingbot ("* Bingbot")
├─DuckDuckBot ("* DuckDuckBot")
├─Googlebot ("* Googlebot")
├─MojeekBot ("MojeekBot")
├─Neevabot ("* Neevabot")
├─PetalBot ("* PetalBot")
├─Qwantify ("Qwantify/Bleriot")
├─SeznamBot ("SeznamBot")
├─Sogou ("* Sogou/搜狗")
├─Yahoo ("Yahoo/Slurp")
├─Yandex ("* Yandex/Яндекс")
└─YoudaoBot ("YoudaoBot")
ما هي "الإيجابيات" و "السلبيات"؟ عند التحقق من الهوية المقدمة من خلال الطلب، يمكن وصف النتيجة الناجحة بأنها "إيجابية" أو "سلبية". عندما يتم التأكد من أن الهوية المقدمة هي الهوية الحقيقية، فإنها توصف بأنها "إيجابية". عندما يتم التأكد من تزوير الهوية المقدمة، توصف بأنها "سلبية". ومع ذلك، فإن النتيجة غير الناجحة (على سبيل المثال، فشل التحقق، أو عدم إمكانية تحديد صحة الهوية المقدمة) لن يتم وصفها بأنها "إيجابية" أو "سلبية". بدلاً من ذلك، يمكن وصف النتيجة غير الناجحة ببساطة بأنها لم يتم التحقق منها. عندما لا يتم إجراء أي محاولة للتحقق من الهوية المقدمة من خلال طلب ما، فسيتم وصف الطلب بالمثل بأنه لم يتم التحقق منه. لا تكون المصطلحات منطقية إلا في السياق الذي يتم فيه التعرف على الهوية المقدمة من خلال الطلب، وبالتالي، حيث يكون التحقق ممكنًا. إذا كانت الهوية المقدمة لا تتطابق مع الخيارات المذكورة أعلاه، أو إذا لم يتم تقديم هوية، فإن الخيارات المقدمة أعلاه تصبح غير ملائمة.
ما هي "التجاوزات بضربة واحدة"؟ في بعض الحالات، قد يظل طلب التحقق الإيجابي محظورًا نتيجة لملفات التوقيع أو الوحدات النمطية أو الشروط الأخرى للطلب، وقد تكون التجاوزات ضرورية لتجنب الإيجابيات الخاطئة. عندما يكون القصد من التجاوز التعامل مع مخالفة واحدة بالضبط، لا أكثر ولا أقل، يمكن وصف هذا التجاوز بأنه "التجاوزات بضربة واحدة".
- هذا الخيار له تجاوز مناظر تحت
used⬅bypasses. يوصى بالتأكد من وضع علامة على خانة الاختيار الخاصة بالتجاوز المقابل بنفس طريقة مربع الاختيار لمحاولة التحقق من هذا الخيار.
- آلية الرقابة للتحقق من الطلبات الواردة من منصات التواصل الاجتماعي.
social_media
├─Embedly ("* Embedly")
├─Facebook ("** Facebook")
├─Pinterest ("* Pinterest")
├─Snapchat ("* Snapchat")
└─Twitterbot ("*!! Twitterbot")
ما هي "الإيجابيات" و "السلبيات"؟ عند التحقق من الهوية المقدمة من خلال الطلب، يمكن وصف النتيجة الناجحة بأنها "إيجابية" أو "سلبية". عندما يتم التأكد من أن الهوية المقدمة هي الهوية الحقيقية، فإنها توصف بأنها "إيجابية". عندما يتم التأكد من تزوير الهوية المقدمة، توصف بأنها "سلبية". ومع ذلك، فإن النتيجة غير الناجحة (على سبيل المثال، فشل التحقق، أو عدم إمكانية تحديد صحة الهوية المقدمة) لن يتم وصفها بأنها "إيجابية" أو "سلبية". بدلاً من ذلك، يمكن وصف النتيجة غير الناجحة ببساطة بأنها لم يتم التحقق منها. عندما لا يتم إجراء أي محاولة للتحقق من الهوية المقدمة من خلال طلب ما، فسيتم وصف الطلب بالمثل بأنه لم يتم التحقق منه. لا تكون المصطلحات منطقية إلا في السياق الذي يتم فيه التعرف على الهوية المقدمة من خلال الطلب، وبالتالي، حيث يكون التحقق ممكنًا. إذا كانت الهوية المقدمة لا تتطابق مع الخيارات المذكورة أعلاه، أو إذا لم يتم تقديم هوية، فإن الخيارات المقدمة أعلاه تصبح غير ملائمة.
ما هي "التجاوزات بضربة واحدة"؟ في بعض الحالات، قد يظل طلب التحقق الإيجابي محظورًا نتيجة لملفات التوقيع أو الوحدات النمطية أو الشروط الأخرى للطلب، وقد تكون التجاوزات ضرورية لتجنب الإيجابيات الخاطئة. عندما يكون القصد من التجاوز التعامل مع مخالفة واحدة بالضبط، لا أكثر ولا أقل، يمكن وصف هذا التجاوز بأنه "التجاوزات بضربة واحدة".
- هذا الخيار له تجاوز مناظر تحت
used⬅bypasses. يوصى بالتأكد من وضع علامة على خانة الاختيار الخاصة بالتجاوز المقابل بنفس طريقة مربع الاختيار لمحاولة التحقق من هذا الخيار.
** يتطلب وظيفة بحث ASN (على سبيل المثال، عبر وحدة IP-API أو وحدة BGPView).
*!! احتمالية عالية للتسبب في نتائج إيجابية خاطئة بسبب iMessage.
- آلية الرقابة للتحقق من أنواع الطلبات الأخرى حيثما أمكن ذلك.
other
├─AdSense ("AdSense")
├─AmazonAdBot ("* AmazonAdBot")
├─ChatGPT-User ("!! ChatGPT-User")
├─GPTBot ("!! GPTBot")
└─Grapeshot ("* Oracle Data Cloud Crawler (Grapeshot)")
ما هي "الإيجابيات" و "السلبيات"؟ عند التحقق من الهوية المقدمة من خلال الطلب، يمكن وصف النتيجة الناجحة بأنها "إيجابية" أو "سلبية". عندما يتم التأكد من أن الهوية المقدمة هي الهوية الحقيقية، فإنها توصف بأنها "إيجابية". عندما يتم التأكد من تزوير الهوية المقدمة، توصف بأنها "سلبية". ومع ذلك، فإن النتيجة غير الناجحة (على سبيل المثال، فشل التحقق، أو عدم إمكانية تحديد صحة الهوية المقدمة) لن يتم وصفها بأنها "إيجابية" أو "سلبية". بدلاً من ذلك، يمكن وصف النتيجة غير الناجحة ببساطة بأنها لم يتم التحقق منها. عندما لا يتم إجراء أي محاولة للتحقق من الهوية المقدمة من خلال طلب ما، فسيتم وصف الطلب بالمثل بأنه لم يتم التحقق منه. لا تكون المصطلحات منطقية إلا في السياق الذي يتم فيه التعرف على الهوية المقدمة من خلال الطلب، وبالتالي، حيث يكون التحقق ممكنًا. إذا كانت الهوية المقدمة لا تتطابق مع الخيارات المذكورة أعلاه، أو إذا لم يتم تقديم هوية، فإن الخيارات المقدمة أعلاه تصبح غير ملائمة.
ما هي "التجاوزات بضربة واحدة"؟ في بعض الحالات، قد يظل طلب التحقق الإيجابي محظورًا نتيجة لملفات التوقيع أو الوحدات النمطية أو الشروط الأخرى للطلب، وقد تكون التجاوزات ضرورية لتجنب الإيجابيات الخاطئة. عندما يكون القصد من التجاوز التعامل مع مخالفة واحدة بالضبط، لا أكثر ولا أقل، يمكن وصف هذا التجاوز بأنه "التجاوزات بضربة واحدة".
- هذا الخيار له تجاوز مناظر تحت
used⬅bypasses. يوصى بالتأكد من وضع علامة على خانة الاختيار الخاصة بالتجاوز المقابل بنفس طريقة مربع الاختيار لمحاولة التحقق من هذا الخيار.
!! من المحتمل أن يرغب معظم المستخدمين في حظر هذا، بغض النظر عما إذا كان حقيقيًا أو مزيفًا. يمكن تحقيق ذلك من خلال عدم تحديد "محاولة التحقق" واختيار "حظر الطلبات التي لم يتم التحقق منها". ومع ذلك، نظرًا لأن بعض المستخدمين قد يرغبون في التمكن من التحقق من هذه الطلبات (من أجل حظر السلبيات مع السماح بالإيجابيات)، فبدلاً من حظر مثل هذه الطلبات عبر الوحدات النمطية، يتم توفير خيارات للتعامل مع هذه الطلبات هنا.
- آلية لضبط الميزات الأخرى عندما تكون في سياق التحقق.
adjust
├─Negatives ("السلبيات المحظورة")
└─NonVerified ("المحظور التي لم يتم التحقق")
التكوين ل ReCaptcha (يوفر وسيلة للبشر لاستعادة الوصول عند حجبه).
- متى يجب تقديم الCAPTCHA؟ ملاحظة: لا تحتاج الطلبات المدرجة في القائمة البيضاء أو التي تم التحقق منها والتي لم يتم حظرها إلى إكمال اختبار CAPTCHA. لاحظ أيضًا: يمكن أن توفر اختبارات CAPTCHA طبقة إضافية مفيدة من الحماية ضد الروبوتات وأنواع مختلفة من الطلبات الآلية الضارة، ولكنها لن توفر أي حماية ضد أي شخص ضار.
usemode
├─0 (أبدا !!!)
├─1 (فقط عندما يتم حظره، ضمن حدود التواقيع، وليس محظور.)
├─2 (فقط عندما يتم حظره، ويتم تمييزها خصيصًا للاستخدام، وضمن حدود التواقيع، وليس محظور.)
├─3 (فقط عندما ضمن حدود التواقيع، وليس محظور (بغض النظر عما إذا كان حظره).)
├─4 (فقط عندما لا يتم حظره.)
├─5 (فقط عندما لا يتم حظره، أو عندما يتم تمييزها خصيصًا للاستخدام، وضمن حدود التواقيع، وليس محظور.)
└─6 (فقط عندما لا يتم حظره، عند طلبات الصفحات الحساسة.)
- القفل CAPTCHA إلى IP؟
- القفل CAPTCHA إلى المستخدمين؟
- يمكن العثور على هذه القيمة في لوحة التحكم الخاصة بخدمة CAPTCHA.
أنظر أيضا:
- يمكن العثور على هذه القيمة في لوحة التحكم الخاصة بخدمة CAPTCHA.
أنظر أيضا:
- عدد الساعات لنتذكر حالات اختبار CAPTCHA. الافتراضي = 720 (١ شهر).
- تسجيل جميع محاولات اختبار CAPTCHA؟ إذا كانت الإجابة بنعم، حدد اسم لاستخدامه في ملف السجل. ان لم، ترك هذا الحقل فارغا.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- الحد الأقصى لعدد التوقيعات المسموح بها قبل سحب عرض CAPTCHA. افتراضي = 1.
- أي API لاستخدام؟
api
├─V2 ("V2 (خانة اختيار)")
└─Invisible ("V2 (غير مرئى)")
- إظهار تحذير ملف تعريف الارتباط؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- إظهار رسالة API؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- ما هو رمز الحالة الذي يجب استخدامه عند عرض CAPTCHA للطلبات غير المحظورة؟
nonblocked_status_code
├─200 (200 OK (حسنا)): أقل قوة، ولكن الأكثر سهولة في الاستخدام.
│ من المرجح أن تفسر الطلبات الآلية هذه
│ الاستجابة على أنها إشارة إلى نجاح الطلب.
├─403 (403 Forbidden (مُحرَّم)): أكثر قوة، ولكن أقل سهولة في الاستخدام.
│ موصى به لمعظم الظروف العامة.
├─418 (418 I'm a teapot (أنا إبريق شاي)): يشير إلى نكتة كذبة أبريل (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). من غير المحتمل
│ جدًا أن يفهمه أي عميل أو روبوت أو متصفح أو
│ غير ذلك. يتم توفيرها للتسلية والراحة،
│ ولكن لا يوصى بها بشكل عام.
├─429 (429 Too Many Requests (طلبات كثيرة جدا)): يوصى به لتحدود معدل، عند التعامل مع هجمات
│ DDoS، وللوقاية من الفيضانات. لا ينصح به في
│ سياقات أخرى.
└─451 (451 Unavailable For Legal Reasons (غير متاح لأسباب قانونية)): يوصى به عند الحظر لأسباب قانونية في
المقام الأول. لا ينصح به في سياقات أخرى.
التكوين ل HCaptcha (يوفر وسيلة للبشر لاستعادة الوصول عند حجبه).
- متى يجب تقديم الCAPTCHA؟ ملاحظة: لا تحتاج الطلبات المدرجة في القائمة البيضاء أو التي تم التحقق منها والتي لم يتم حظرها إلى إكمال اختبار CAPTCHA. لاحظ أيضًا: يمكن أن توفر اختبارات CAPTCHA طبقة إضافية مفيدة من الحماية ضد الروبوتات وأنواع مختلفة من الطلبات الآلية الضارة، ولكنها لن توفر أي حماية ضد أي شخص ضار.
usemode
├─0 (أبدا !!!)
├─1 (فقط عندما يتم حظره، ضمن حدود التواقيع، وليس محظور.)
├─2 (فقط عندما يتم حظره، ويتم تمييزها خصيصًا للاستخدام، وضمن حدود التواقيع، وليس محظور.)
├─3 (فقط عندما ضمن حدود التواقيع، وليس محظور (بغض النظر عما إذا كان حظره).)
├─4 (فقط عندما لا يتم حظره.)
├─5 (فقط عندما لا يتم حظره، أو عندما يتم تمييزها خصيصًا للاستخدام، وضمن حدود التواقيع، وليس محظور.)
└─6 (فقط عندما لا يتم حظره، عند طلبات الصفحات الحساسة.)
- القفل CAPTCHA إلى IP؟
- القفل CAPTCHA إلى المستخدمين؟
- يمكن العثور على هذه القيمة في لوحة التحكم الخاصة بخدمة CAPTCHA.
أنظر أيضا:
- يمكن العثور على هذه القيمة في لوحة التحكم الخاصة بخدمة CAPTCHA.
أنظر أيضا:
- عدد الساعات لنتذكر حالات اختبار CAPTCHA. الافتراضي = 720 (١ شهر).
- تسجيل جميع محاولات اختبار CAPTCHA؟ إذا كانت الإجابة بنعم، حدد اسم لاستخدامه في ملف السجل. ان لم، ترك هذا الحقل فارغا.
نصيحة مفيدة: يمكنك إرفاق معلومات التاريخ/الوقت بأسماء ملفات السجل باستخدام العناصر النائبة لتنسيق الوقت. يتم عرض العناصر النائبة لتنسيق الوقت المتوفرة عند general➡time_format.
- الحد الأقصى لعدد التوقيعات المسموح بها قبل سحب عرض CAPTCHA. افتراضي = 1.
- أي API لاستخدام؟
api
├─V1 ("V1")
└─Invisible ("V1 (غير مرئى)")
- إظهار تحذير ملف تعريف الارتباط؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- إظهار رسالة API؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- ما هو رمز الحالة الذي يجب استخدامه عند عرض CAPTCHA للطلبات غير المحظورة؟
nonblocked_status_code
├─200 (200 OK (حسنا)): أقل قوة، ولكن الأكثر سهولة في الاستخدام.
│ من المرجح أن تفسر الطلبات الآلية هذه
│ الاستجابة على أنها إشارة إلى نجاح الطلب.
├─403 (403 Forbidden (مُحرَّم)): أكثر قوة، ولكن أقل سهولة في الاستخدام.
│ موصى به لمعظم الظروف العامة.
├─418 (418 I'm a teapot (أنا إبريق شاي)): يشير إلى نكتة كذبة أبريل (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). من غير المحتمل
│ جدًا أن يفهمه أي عميل أو روبوت أو متصفح أو
│ غير ذلك. يتم توفيرها للتسلية والراحة،
│ ولكن لا يوصى بها بشكل عام.
├─429 (429 Too Many Requests (طلبات كثيرة جدا)): يوصى به لتحدود معدل، عند التعامل مع هجمات
│ DDoS، وللوقاية من الفيضانات. لا ينصح به في
│ سياقات أخرى.
└─451 (451 Unavailable For Legal Reasons (غير متاح لأسباب قانونية)): يوصى به عند الحظر لأسباب قانونية في
المقام الأول. لا ينصح به في سياقات أخرى.
التكوين للمتطلبات القانونية.
- إخفاء عناوين IP عند كتابة السجلات؟ صحيح/True = نعم [افتراضي]؛ زائفة/False = لا.
- عنوان سياسة الخصوصية ذات الصلة ليتم عرضها في تذييل الصفحات التي تم إنشاؤها. حدد عنوان URL، أو اتركه فارغًا لتعطيله.
التكوين للقوالب والسمات.
- الموضوع الافتراضي لاستخدام CIDRAM.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…آخر
- تكبير الخط. افتراضي = 1.
- URL ملف CSS لمواضيع مخصصة.
- عنوان الصفحة المراد عرضه لحظر الأحداث.
block_event_title
├─CIDRAM ("CIDRAM")
├─denied ("تم رفض الوصول!")
└─…آخر
- عنوان الصفحة المراد عرضه لطلبات CAPTCHA.
captcha_title
├─CIDRAM ("CIDRAM")
└─…آخر
- تم إدراجها بتنسيق HTML في بداية كافة صفحات "تم رفض الوصول". قد يكون هذا مفيدًا في حالة رغبتك في تضمين شعار موقع ويب أو رأس مخصص أو نصوص أو ما شابه ذلك في جميع هذه الصفحات.
- تم إدراجها بتنسيق HTML في الجزء السفلي من كافة صفحات "تم رفض الوصول". قد يكون هذا مفيدًا في حالة رغبتك في تضمين إشعار قانوني أو رابط اتصال أو معلومات تجارية أو ما شابه ذلك في كل هذه الصفحات.
التكوين للحد من معدل (غير مستحسن للاستخدام العام).
- أقصى قدر من عرض النطاق الترددي المسموح به خلال فترة السماح. عندما يتم تجاوزت، يتم تمكين حدود السعر للطلبات المستقبلية. تعمل القيمة 0 على تعطيل هذا النوع من تحديد السرعة. افتراضي = 0KB.
- الحد الأقصى لعدد الطلبات المسموح بها خلال فترة السماح. عندما يتم تجاوزت، يتم تمكين حدود السعر للطلبات المستقبلية. تعمل القيمة 0 على تعطيل هذا النوع من تحديد السرعة. افتراضي = 0.
- الدقة المستخدمة عند مراقبة استخدام IPv4. قيمة تعكس حجم كتلة CIDR. تعيين إلى 32 للحصول على أفضل دقة. افتراضي = 32.
- الدقة المستخدمة عند مراقبة استخدام IPv6. قيمة تعكس حجم كتلة CIDR. تعيين إلى 128 للحصول على أفضل دقة. افتراضي = 128.
- المدة لمراقبة الاستخدام. افتراضي = 0°0′0″.
- استثناءات (بمعنى آخر، الطلبات التي لا ينبغي أن تكون محدودة). له تأثير فقط عند تمكين الحد.
exceptions
├─Whitelisted ("طلبات القائمة البيضاء")
├─Verified ("الطلبات التي تم التحقق منها من محركات البحث ووسائل التواصل الاجتماعي")
└─FE ("طلبات للواجهة الأمامية CIDRAM")
- هل يجب فصل أو مشاركة الحصص الخاصة بالمجالات والمضيفين المختلفين؟ True = سيتم فصل الحصص. False = سيتم تقاسم الحصص [افتراضي].
خيارات ذاكرة التخزين المؤقت التكميلية. ملاحظة: قد يؤدي تغيير هذه القيم إلى تسجيل خروجك.
- سيتم إضافة القيمة المحددة هنا إلى جميع مفاتيح إدخال ذاكرة التخزين المؤقت. افتراضي = "CIDRAM_". عند وجود عدة عمليات تثبيت على نفس الخادم، يمكن أن يكون ذلك مفيدًا للحفاظ على ذاكرة التخزين المؤقت منفصلة عن بعضها البعض.
- يحدد هذا ما إذا كنت تريد استخدام APCu للتخزين المؤقت. افتراضي = True (صحيح).
- يحدد هذا ما إذا كنت تريد استخدام Memcached للتخزين المؤقت. افتراضي = False (زائفة).
- يحدد هذا ما إذا كنت تريد استخدام Redis للتخزين المؤقت. افتراضي = False (زائفة).
- يحدد هذا ما إذا كنت تريد استخدام PDO للتخزين المؤقت. افتراضي = False (زائفة).
- قيمة المضيف Memcached. افتراضي = "localhost".
- قيمة منفذ Memcached. افتراضي = "11211".
- قيمة المضيف Redis. افتراضي = "localhost".
- قيمة منفذ Redis. افتراضي = "6379".
- Redis قيمة المهلة. افتراضي = "2.5".
- رقم قاعدة بيانات Redis. افتراضي = 0. ملاحظة: لا يمكن استخدام قيم غير 0 مع Redis Cluster.
- قيمة PDO DSN. افتراضي = "mysql:dbname=cidram;host=localhost;port=3306".
FAQ. ما هو "PDO DSN"؟ كيف يمكنني استخدام PDO مع CIDRAM؟
- PDO اسم المستخدم.
- PDO كلمه السر.
التكوين لتجاوز التوقيع الافتراضي.
- ما هي التجاوزات التي يجب استخدامها؟
used
├─AbuseIPDB ("AbuseIPDB")
├─AmazonAdBot ("AmazonAdBot")
├─Baidu ("Baiduspider/百度")
├─Bingbot ("Bingbot")
├─DuckDuckBot ("DuckDuckBot")
├─Embedly ("Embedly")
├─Feedbot ("Feedbot")
├─Feedspot ("Feedspot")
├─GoogleFiber ("Google Fiber")
├─Googlebot ("Googlebot")
├─Grapeshot ("Grapeshot")
├─Jetpack ("Jetpack")
├─Neevabot ("Neevabot")
├─PetalBot ("PetalBot")
├─Pinterest ("Pinterest")
├─Redditbot ("Redditbot")
├─Snapchat ("Snapchat")
├─Sogou ("Sogou/搜狗")
└─Yandex ("Yandex/Яндекс")
أنظر أيضا:
جميع التوقيعات من IPv4 تتبع هذا الشكل: "xxx.xxx.xxx.xxx/yy [وظيفة] [معامل]".
- "xxx.xxx.xxx.xxx" يمثل بداية كتلة CIDR (المجموعة ثمانية من عنوان IP الأول).
- "yy" تمثل حجم الكتلة [١-٣٢].
- "[وظيفة]" يرشد النصي ما يجب القيام به مع التوقيع.
- "[معامل]" تمثل أي معلومات إضافية قد تكون مطلوبة من قبل "[وظيفة]".
جميع التوقيعات من IPv6 تتبع هذا الشكل:
"xxxx:xxxx:xxxx:xxxx::xxxx/yy" [وظيفة] [معامل]"."xxxx:xxxx:xxxx:xxxx::xxxx"يمثل بداية كتلة CIDR (المجموعة ثمانية من عنوان IP الأول). تدوين كامل وتدوين يختصر على حد سواء مقبول (كل يجب أن تلتزم المعايير تدوين الإصدار IPv6، ولكن مع استثناء واحد: عنوان IPv6 لا يمكن أبدا أن تبدأ مع اختصار عند استخدامها في التوقيع لهذا النصي، بسبب الطريقة التي يتم بناؤها CIDRs؛ فمثلا،"::1/128"ينبغي التعبير، عند استخدامها في توقيع، كما"0::1/128"، و"::0/128" التعبير بأنه"0::/128").- "yy" تمثل حجم الكتلة [١-١٢٨].
- "[وظيفة]" يرشد النصي ما يجب القيام به مع التوقيع.
- "[معامل]" تمثل أي معلومات إضافية قد تكون مطلوبة من قبل "[وظيفة]".
أسطر جديدة يونكس الموصى بها (
"%0A"، أو "\n")! أسطر جديدة أخرى (على سبيل المثال، Windows "%0D%0A" أو أسطر جديدة "\r\n"، Mac "%0D" أو أسطر جديدة "\r"، إلخ) يمكن استخدامها، ولكن لا يفضل. أسطر جديدة تطبيع من قبل البرنامج النصي.يجب أن يكون تدوين CIDR دقيق. يجب أن أعداد تقسم بالتساوي (على سبيل المثال، من أجل الحيلولة دون
"10.128.0.0"-"11.127.255.255"، "10.128.0.0/8" لن تكون صالحة، لكن "10.128.0.0/9" و"11.0.0.0/9" على ما يرام).أي شيء لذا أوقع الذي يعني أنك يمكن أن تريد بأمان في ملفات توقيعك دون انقطاع دون اقتحام والكتابات التي وضعت البيانات في أي غير الموقعة، و سيتم تجاهل رأي ولا كدليل على الاعتراف بأنه بناء الجملة من توقيع الملفات النصي. التعليقات هي ملفات التوقيع مقبولة، وأي تنسيق خاص اللازمة لها. على غرار قذيفة المفضل التجزئة للحصول على تعليق، ولكن لا تفرض أي، يستحق ذلك تماما، فإنه لا يحدث أي فارق أو لم النصي اختيار استخدام التجزئة على غرار قذيفة على تعليقاتكم، ولكن التجزئة على غرار قذيفة استخدام برامج تحرير النصوص واضحة وبيئات التطوير يساعد على تسليط الضوء وقعت أجزاء من الملفات بشكل صحيح (وبالتالي، يمكن أن تساعد باعتبارها المساعدات البصرية في حالة وضع تحرير التجزئة).
القيم الممكنة من "[وظيفة]" هي كما يلي:
- Run
- Whitelist
- Greylist
- Deny
إذا تم استخدام "Run"، عندما يتم تشغيل توقيع، السيناريو سوف محاولة لتنفيذ برنامج نصي خارجية (استخدام علامة "require_once" بيان)، التي تحددها قيمة "[معامل]" (الدليل يجب أن يكون الدليل "/vault/" البرنامج النصي؛ راجع الأمثلة أدناه).
127.0.0.0/8 Run example.php
يمكن أن يكون هذا مفيدا لتشغيل كود PHP معين لبعض عناوين IP و CIDRs.
إذا تم استخدام "Whitelist"، عندما يتم تشغيل توقيع، البرنامج النصي إعادة تعيين كافة المكتشفة والانتهاء من عملية. "[معامل]" يتم تجاهل (راجع الأمثلة أدناه).
127.0.0.1/32 Whitelist
إذا تم استخدام "Greylist"، عندما يتم تشغيل توقيع، البرنامج النصي إعادة تعيين كافة المكتشفة وانتقل إلى ملف التوقيع المقبل. "[معامل]" يتم تجاهل (راجع الأمثلة أدناه).
127.0.0.1/32 Greylist
إذا تم استخدام "Deny"، عندما يتم تشغيل توقيع، إن لم يكن في القائمة البيضاء، سيتم رفض الوصول. "Deny" يستخدم لمنع عنوان IP أو CIDR.
"[معامل]" قيمة لديها دعم L10N.
الكلمات المختزلة المتاحة هي:
- Attacks
- Bogon
- Cloud
- Generic
- Legal
- Malware
- Proxy
- Spam
يمكنك تحديد أقسام مختلفة مثل هذا (راجع الأمثلة أدناه).
# القسم 1.
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
6.7.8.9/32 Deny Proxy
Tag: القسم ١
خطوط مزدوجة يمكن استخدامها لأقسام منفصلة (راجع الأمثلة أدناه).
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
Tag: القسم ١
في المثال أعلاه
"1.2.3.4/32" و"2.3.4.5/32" وصفت بأنها "IPv4"، بينما"4.5.6.7/32" و"5.6.7.8/32" وصفت بأنها "القسم 1".ويمكن تطبيق المنطق نفسه لفصل الأنواع الأخرى من العلامات أيضا.
على وجه الخصوص، يمكن أن تكون علامات القسم مفيدة جدا لتصحيح الأخطاء عندما تحدث ايجابيات كاذبة، من خلال توفير وسيلة سهلة من موقع المصدر الدقيق للمشكلة، ويمكن أن تكون مفيدة جدا لتصفية إدخالات ملف السجل عند عرض ملفات السجل عبر صفحة سجلات الواجهة الأمامية (يمكن النقر على أسماء الأقسام عبر صفحة سجلات الواجهة الأمامية ويمكن استخدامها كمعايير تصفية). إذا تم حذف علامات الأقسام لبعض التواقيع المحددة، عندما يتم تشغيل تلك التوقيعات، يستخدم CIDRAM اسم ملف التوقيع مع نوع عنوان إب المحظور (IPv4 أو IPv6) كمرجع، وبالتالي، الأقسام القسم اختيارية تماما. ويمكن التوصية في بعض الحالات، على سبيل المثال، عندما تكون ملفات التوقيع مسماة بشكل غامض أو عندما يكون من الصعب على نحو آخر تحديد مصدر التوقيعات بشكل واضح مما يتسبب في حظر الطلب.
في المثال التالي، سوف التوقيعات تنتهي بعد مرور بعض الوقت:
# القسم ١.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Expires: 2016.12.31
لن يتم تشغيل التوقيعات منتهية الصلاحية على أي طلب، بغض النظر عن ما.
إذا كنت ترغب في تحديد بلد المنشأ لبعض التوقيع معين، يمكنك القيام بذلك باستخدام "علامة المنشأ". تقبل علامة الأصل شفرة "أيزو 3166-1 حرفي-2" المقابلة لبلد المنشأ للتوقيعات التي تنطبق عليها. يجب أن تكون هذه الرموز مكتوبة في الحالة العليا (أقل حالة أو حالة مختلطة لن تجعل بشكل صحيح). عند استخدام علامات المنشأ، يتم إضافته إلى إدخال حقل السجل "سبب الحظر" لأي طلبات تم حظرها نتيجة للتوقيعات التي يتم تطبيق العلامة عليها.
إذا تم تثبيت مكون "flags CSS" الاختياري، عند عرض ملفات السجل عبر صفحة سجلات الواجهة الأمامية، يتم استبدال المعلومات الملحقة بعلامات المنشأ بعلامة البلد المقابل لتلك المعلومات. هذه المعلومات، سواء في شكلها الخام أو كعلامة بلد، يمكن النقر عليها، وعند النقر عليها، سيتم تصفية إدخالات السجل عن طريق إدخالات سجل تعريف أخرى مماثلة (مما يسمح على نحو فعال للأشخاص الذين يدخلون إلى صفحة السجلات بالترشيح عن طريق بلد المنشأ).
ملاحظة: من الناحية الفنية، هذا ليس أي شكل من أشكال تحديد الموقع الجغرافي، وذلك لأنه لا ينطوي على البحث عن أي معلومات محددة تتعلق عناوين بروتوكول الإنترنت الواردة، وإنما بدلا من ذلك، يسمح ببساطة لنا أن ينص صراحة بلد المنشأ لأي طلبات تم حظرها من قبل محددة التوقيعات. علامات المنشأ المتعددة مسموح بها في نفس قسم التوقيع.
مثال افتراضي:
1.2.3.4/32 Deny Generic
Origin: CN
2.3.4.5/32 Deny Generic
Origin: FR
4.5.6.7/32 Deny Generic
Origin: DE
6.7.8.9/32 Deny Generic
Origin: US
Tag: Foobar
يمكن استخدام أي علامات بالتزامن، وتكون جميع العلامات اختيارية (راجع الأمثلة أدناه).
# القسم المثال.
1.2.3.4/32 Deny Generic
Origin: US
Tag: القسم المثال
Expires: 2016.12.31
عندما يتم تثبيت أعداد كبيرة من ملفات التوقيع واستخدامها بنشاط، يمكن أن تصبح عمليات التثبيت معقدة للغاية، وقد تكون هناك بعض التواقيع التي تتداخل. في هذه الحالات، لضمان أن التوقيعات المتعددة والمتداخلة لا يتم تشغيلها جميعًا أثناء أحداث الحظر، علامات احترام يمكن استخدامه لتأجيل أقسام محددة للتوقيع في الحالات التي يتم فيها تثبيت بعض ملفات التوقيع المحددة واستخدامها بشكل نشط. قد يكون هذا مفيدًا في الحالات التي يتم فيها تحديث بعض التوقيعات بشكل متكرر أكثر من غيرها، وذلك لتأجيل التواقيع الأقل تحديثًا بشكل متكرر لصالح التوقيعات الأكثر تكرارًا.
يتم استخدام علامات احترام بشكل مشابه للأنواع الأخرى من العلامات. يجب أن تتطابق قيمة العلامة مع ملف التوقيع المثبت والمستخدم بشكل فعال ليتم تأجيله.
مثال:
1.2.3.4/32 Deny Generic
Origin: AA
2.3.4.5/32 Deny Generic
Origin: BB
Defers to: preferred_signatures.dat
توفر علامات الملف الشخصي وسيلة تعرض معلومات إضافية في صفحة اختبار IP، ويمكن الاستفادة منها من خلال الوحدات النمطية والقواعد المساعدة لسلوك أكثر تعقيدًا واتخاذ قرارات دقيقة.
يتم استخدام علامات الملف الشخصي بشكل مشابه لأنواع أخرى من العلامات. يمكن استخدام قيم علامات الملف الشخصي كشرط للوحدات النمطية والقواعد المساعدة. يمكن أن توفر علامات ملف التعريف قيمًا متعددة عن طريق فصل هذه القيم بفاصلة منقوطة. لا يرى المستخدم النهائي أبدًا قيم علامات الملف الشخصي.
مثال:
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Profile: Example;Just some generic stuff;Foo;Bar
Origin: BB
باستخدام YAML العلامات اختياري كلي (أي، إذا كنت تستخدم ذلك، هو اختيارك)، وغير قادرة على الاستفادة من معظم التكوين.
في CIDRAM، يتم تحديد YAML باستخدام ثلاث شرطات ("---")، و انهم إنهاء باستخدام اثنين أسطر جديدة. مثال التالي:
# Foobar 1.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 1
---
general:
http_response_header_code: 403
emailaddr: username@domain.tld
logging:
standard_log: "logfile.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.{yyyy}-{mm}-{dd}.txt"
recaptcha:
lockip: false
lockuser: true
expiry: 720
recaptcha_log: "recaptcha.{yyyy}-{mm}-{dd}.txt"
enabled: true
template_data:
css_url: "https://domain.tld/cidram.css"
# Foobar 2.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 2
---
general:
http_response_header_code: 503
logging:
standard_log: "logfile.Foobar2.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.Foobar2.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.Foobar2.{yyyy}-{mm}-{dd}.txt"
# Foobar 3.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 3
---
general:
http_response_header_code: 403
silent_mode: "http://127.0.0.1/"
عندما "usemode" هو 2 أو 5، من أجل دلالة أقسام توقيع للاستخدام مع اختبار reCAPTCHA/hCAPTCHA، تشير إلى أن في YAML لهذا القسم التوقيع (راجع الأمثلة أدناه).
1.2.3.4/32 Deny Generic 2.3.4.5/32 Deny Generic Tag: CAPTCHA Marked --- recaptcha: enabled: true hcaptcha: enabled: true
إذا كنت تريد CIDRAM تجاهل تماما بعض المقاطع، يمكنك استخدام ملف "ignore.dat" لتحديد المقاطع التي ليمكن تجاهلها. على سطر جديد، اكتب "Ignore"، متبوعا بمسافة، يليه اسم المقطع ليمكن تجاهله (راجع الأمثلة أدناه).
Ignore القسم ١
ويمكن تحقيق ذلك أيضًا من خلال صفحة "لقائمة الأقسام" CIDRAM لfront-end.
إذا كنت تشعر أن كتابة ملفات التوقيع المخصصة الخاصة بك أو وحدات مخصصة معقدة للغاية بالنسبة لك، قد يكون بديل أبسط هو استخدام صفحة "القواعد المساعدة" الخاصة بـ CIDRAM لfront-end. من خلال تحديد الخيارات المناسبة وتحديد تفاصيل حول أنواع معينة من الطلبات، يمكنك توجيه CIDRAM إلى كيفية الرد على تلك الطلبات. يتم تنفيذ "القواعد المساعدة" بعد الانتهاء من جميع ملفات التوقيع والوحدات النمطية بالفعل التنفيذ.
وحدات يمكن استخدامها لتوسيع وظائف CIDRAM، أداء مهام إضافية، أو معالجة منطق إضافي.
لأن يتم كتابة وحدات كملفات PHP، إذا كنت على دراية كافية مع مصدر برنامج CIDRAM، يمكنك هيكلة وحدات المكون التواقيع ولكن تريد (في إطار ما هو ممكن مع فب).
ملحوظة: إذا كنت غير مريح العمل مع التعليمات البرمجية PHP، كتابة الوحدات الخاصة بك لا ينصح.
يتم توفير بعض الوظائف من قبل CIDRAM التي ينبغي أن تجعل من أبسط وأسهل لكتابة وحدات الخاصة بك. وترد أدناه معلومات عن هذه الوظيفة.
وعادة ما تكتب تواقيع المكون مع
$this->trigger. في معظم الحالات، هذا الإغلاق سيكون أكثر أهمية من أي شيء آخر لغرض كتابة وحدات.$this->trigger يقبل ٤ المعلمات: $Condition، $ReasonShort، $ReasonLong (اختياري)، $DefineOptions (اختياري).يتم تقييم
$Condition، وإذا كان "صحيح" (true)، التوقيع نشط. إذا كان "خاطئة" (false)، التوقيع غير نشط. $Condition عادة ما تحتوي على التعليمات البرمجية PHP التي يجب منع الطلبات.$ReasonShort في حقل "سبب الحظر" عندما يكون التوقيع نشطا.$ReasonLong هي رسالة اختيارية يتم عرضها للمستخدم عند حظرها، لشرح سبب حظرها. يستخدم الرسالة القياسية "سبب الحظر" عند حذفها.$DefineOptions عبارة عن صفيف اختياري يحتوي على أزواج المفاتيح/القيم التي تحدد خيارات التكوين الخاصة بمثيل الطلب. سيتم تطبيق خيارات التهيئة عندما يكون التوقيع نشطا.ترجع
$this->trigger صحيح (true) عندما يكون التوقيع نشطا و خاطئة (false) عندما لا يكون.وعادة ما تكتب الالتفافية التوقيع مع
$this->bypass.$this->bypass يقبل ٣ المعلمات: $Condition، $ReasonShort، $DefineOptions (اختياري).يتم تقييم
$Condition، وإذا كان "صحيح" (true)، الالتفافية نشط. إذا كان "خاطئة" (false)، الالتفافية غير نشط. $Condition عادة ما تحتوي على رمز PHP التي يجب عدم منع الطلبات.$ReasonShort في حقل "سبب الحظر" عندما يكون الالتفافية نشطا.$DefineOptions عبارة عن صفيف اختياري يحتوي على أزواج المفاتيح/القيم التي تحدد خيارات التكوين الخاصة بمثيل الطلب. سيتم تطبيق خيارات التهيئة عندما يكون الالتفافية نشطا.ترجع
$this->bypass صحيح (true) عندما يكون الالتفافية نشطا و خاطئة (false) عندما لا يكون.يمكن استخدام هذا لجلب اسم المضيف لعنوان IP. إذا كنت ترغب في إنشاء المكون لمنع أسماء المضيفين، قد يكون هذا الإغلاق مفيدا.
مثال:
<?php
/** Fetch hostname. */
if (empty($this->CIDRAM['Hostname'])) {
$this->CIDRAM['Hostname'] = $this->dnsReverse($this->BlockInfo['IPAddr']);
}
/** Example signature. */
if (strlen($this->CIDRAM['Hostname']) && $this->CIDRAM['Hostname'] !== $this->BlockInfo['IPAddr']) {
$this->trigger($this->CIDRAM['Hostname'] === 'www.foobar.tld', 'Foobar.tld', 'Hostname Foobar.tld is not allowed.');
}الوحدات النمطية تنفذ ضمن نطاقها الخاص، وأي متغيرات محددة من قبل المكون نمطية، لن تكون في متناول وحدات أخرى، أو إلى السيناريو الأصل، إلا إذا كانت مخزنة في
$CIDRAM مجموعة (يتم مسح كل شيء آخر بعد انتهاء تنفيذ المكون).فيما يلي بعض المتغيرات الشائعة التي قد تكون مفيدة للالمكون النمطية الخاصة بك:
| وصف |
متغير |
|---|---|
| التاريخ والوقت الحاليان. |
$this->BlockInfo['DateTime'] |
| عنوان IP للطلب الحالي. |
$this->BlockInfo['IPAddr'] |
| إصدار النص البرمجي CIDRAM. |
$this->BlockInfo['ScriptIdent'] |
| الاستعلام عن الطلب الحالي. |
$this->BlockInfo['Query'] |
| المحيل للطلب الحالي (إذا كان موجودا). |
$this->BlockInfo['Referrer'] |
| وكيل المستخدم (user agent) للطلب الحالي. |
$this->BlockInfo['UA'] |
| وكيل المستخدم (user agent) للطلب الحالي (في حالة أقل). |
$this->BlockInfo['UALC'] |
| الرسالة المراد عرضها للمستخدم عند حظرها. |
$this->BlockInfo['ReasonMessage'] |
| عدد التوقيعات التي أدت إلى الطلب الحالي. |
$this->BlockInfo['SignatureCount'] |
| المعلومات المرجعية عن أي توقيعات أثارت للطلب الحالي. |
$this->BlockInfo['Signatures'] |
| المعلومات المرجعية عن أي توقيعات أثارت للطلب الحالي. |
$this->BlockInfo['WhyReason'] |
تم العثور على الحزم والمنتجات التالية لتكون غير متوافقة مع CIDRAM:
تم توفير وحدات لضمان توافق الحزم والمنتجات التالية مع CIDRAM:
- ما هو "التوقيع"؟
- ما هو "CIDR"؟
- ما هو "إيجابية خاطئة"؟
- يمكن CIDRAM منع الدول؟
- عدد المرات التي يتم تحديثها التوقيعات؟
- لقد واجهت مشكلة! أنا لا أعرف ما يجب القيام به! الرجاء المساعدة!
- لقد تم حظر من موقع على شبكة الانترنت! الرجاء المساعدة!
- أريد استخدام CIDRAM v3 مع نسخة PHP كبار السن من 7.2؛ يمكنك أن تساعد؟
- هل يمكنني استخدام تثبيت CIDRAM واحد لحماية نطاقات متعددة؟
- أنا لا أريد أن تضيع الوقت مع تثبيت هذا أو ضمان أنه يعمل لموقع الويب الخاص بي؛ يمكنني دفع لك أن تفعل ذلك بالنسبة لي؟
- هل يمكنني توظيفك أو أي من مطوري هذا المشروع للعمل الخاص؟
- أنا بحاجة إلى تعديلات متخصصة، والتخصيصات، الخ؛ يمكنك أن تساعد؟
- أنا مطور، مصمم موقع، أو مبرمج. هل يمكنني قبول أو عرض العمل المتعلق بهذا المشروع؟
- أريد أن أساهم في المشروع؛ هل يمكنني فعل هذا؟
- هل يمكنني استخدام cron لتحديث تلقائيا؟
- ما هي "المخالفات"؟
- هل يمكن لأسماء المضيفين في CIDRAM حظر؟
- ما الذي يمكنني استخدامه لـ "default_dns"؟
- هل يمكنني استخدام CIDRAM لحماية الأشياء بخلاف مواقع الويب (مثل خوادم البريد الإلكتروني، FTP، SSH، IRC، إلخ)؟
- هل تحدث مشكلات إذا كنت أستخدم CIDRAM في نفس وقت استخدام خدمات CDN أو خدمات التخزين المؤقت؟
- هل CIDRAM حماية موقعي على الويب ضد هجمات DDoS؟
- عندما أقوم بتنشيط أو إلغاء تنشيط الوحدات النمطية أو ملفات التوقيع عبر صفحة التحديثات، فإنها تقوم بترتيبها أبجديًا في التكوين. هل يمكنني تغيير الطريقة التي يتم تصنيفها بها؟
- ما هو "PDO DSN"؟ كيف يمكنني استخدام PDO مع CIDRAM؟
- CIDRAM يحظر cronjobs؛ كيف يمكن اصلاح هذا؟
في CIDRAM، يشير "التوقيع" إلى البيانات التي تعمل كمعرف، لشيء معين أننا نبحث عنه. عادة عنوان IP أو CIDR، يتضمن بعض التعليمات لCIDRAM، مثل أفضل طريقة للرد عندما يواجه ما نحن نبحث عنه. توقيع نموذجي لCIDRAM يبدو شيئا من هذا القبيل:
بالنسبة إلى "ملفات التوقيع":
1.2.3.4/32 Deny Generic
بالنسبة إلى "الوحدات النمطية":
$this->trigger(strpos($this->BlockInfo['UA'], 'Foobar') !== false, 'Foobar-UA', 'User agent "Foobar" not allowed.');ملاحظة: التوقيعات ل "ملفات التوقيع"، والتوقيعات ل "وحدات"، ليست هي نفس الشيء.
في كثير من الأحيان (ولكن ليس دائما)، سيتم تجميع التواقيع معا في مجموعات، تشكيل "أقسام التوقيع"، وغالبا ما تكون مصحوبة بتعليقات، وترميز، والبيانات الوصفية ذات الصلة. ويمكن استخدام هذا لتوفير سياق إضافي.
"CIDR" هو اختصار ل "Classless Inter-Domain Routing". ("توجيه بين المجالات لافئويا") [١، ٢]. يستخدم هذا الاختصار كجزء من اسم هذه الحزمة، "CIDRAM"، وهو اختصار ل "Classless Inter-Domain Routing Access Manager" (توجيه بين المجالات لافئويا وصول مدير).
ومع ذلك، في سياق CIDRAM (مثل، ضمن هذه الوثائق، في المناقشات ذات الصلة، أو ضمن بيانات اللغة)، عند ذكر "CIDR" (المفرد) أو "CIDRs" (الجمع)، المعنى المقصود لدينا هو الشبكات الفرعية، معربا عن ذلك باستخدام تدوين سيدر. والسبب في ذلك هو أنه يمكن التعبير عن الشبكات الفرعية بطرق مختلفة مختلفة. لذلك يمكن اعتبار CIDRAM "مدير النفاذ إلى الشبكة الفرعية".
وهذا التفسير، والسياق المقدم، ينبغي أن يساعد على حل أي غموض.
المصطلح "إيجابية خاطئة" (بدلا من ذلك: "خطأ إيجابية خاطئة"؛ "انذار خاطئة"؛ الإنجليزية: false positive; false positive error; false alarm)، وصف ببساطة، بشكل عام، يستخدم عند اختبار حالة، للإشارة إلى نتائج هذا الاختبار، عندما تكون النتائج إيجابية (أي، تحديد حالة أن يكون "إيجابية"، أو "صحيح")، ولكن من المتوقع أن تكون (أو كان ينبغي أن يكون) سلبي (أي، الحالة، في الواقع، هو "سلبي"، أو "خاطئة"). "إيجابية خاطئة" ويمكن اعتبار التناظرية من "الذئب الباكي" (حيث لحالة يجري اختبارها هو ما إذا كان هناك ذئب بالقرب من القطيع، الحالة هو "خاطئة" في أنه لا يوجد الذئب بالقرب من القطيع، و الحالة يقال بأنها "إيجابية" بواسطة الراعي عن طريق الدعوة "الذئب، الذئب")، أو التناظرية من الفحص الطبي حيث المريض يتم تشخيص المرض، عندما تكون في واقع، ليس لديهم المرض.
بعض المصطلحات ذات الصلة هي "إيجابية صحيح"، "سلبي صحيح" و "سلبي خاطئة". "إيجابية صحيح" هو عندما تكون نتائج الاختبار والحالة الفعلية للحالة على حد سواء صحيح (أو "إيجابية")، و "سلبي صحيح" هو عندما تكون نتائج الاختبار والحالة الفعلية للحالة على حد سواء خاطئة (أو "سلبي")؛ "إيجابية صحيح" أو "سلبي صحيح" ويعتبر أن تكون "الاستدلال الصحيح". نقيض ل "إيجابية خاطئة" هو "سلبي خاطئة"؛ "سلبي خاطئة" هو عندما تكون النتائج سلبي (أي، تحديد حالة أن يكون "سلبي"، أو "خاطئة")، ولكن من المتوقع أن تكون (أو كان ينبغي أن يكون) إيجابية (أي، الحالة، في الواقع، هو "إيجابية"، أو "صحيح").
في سياق CIDRAM، هذه المصطلحات تشير إلى التوقيعات CIDRAM و ما/منهم أنهم منع. عندما CIDRAM يمنع عنوان IP نظرا لتوقيع سيئة، قديمة أو غير صحيحة، ولكن لا ينبغي أن تفعل ذلك، أو عندما يفعل ذلك لأسباب خاطئة، نشير إلى هذا الحدث باعتباره "إيجابية خاطئة". عندما CIDRAM يفشل لمنع عنوان IP التي كان ينبغي أن سدت، بسبب تهديدات غير متوقعة، التوقيعات المفقودة أو أوجه القصور توقيع، نشير إلى هذا الحدث باعتباره "افتقد" (هذا هو التناظرية من ا "سلبي خاطئة").
هذا يمكن تلخيصها حسب الجدول أدناه:
| CIDRAM لا ينبغي منع عنوان IP |
CIDRAM يجب منع عنوان IP |
|
|---|---|---|
| سلبي صحيح (الاستدلال الصحيح) |
افتقد (التناظرية من سلبي خاطئة) |
CIDRAM لا يمنع عنوان IP |
| إيجابية خاطئة |
إيجابية صحيح (الاستدلال الصحيح) |
CIDRAM منع عنوان IP |
نعم. أسهل طريقة للقيام بذلك هي تثبيت المكون BGPView وتكوينها وفقًا لاحتياجاتك.
أنه يختلف. نحن نحاول قدر الإمكان، ولكن نظرا لالتزامات أخرى، حياتنا اليومية، وعدم حصولهم على رواتبهم، تحديث الجدول الزمني الدقيق لا يمكن أن تكون مضمونة. الأولوية لضرورة. ورحب المساعدة دائما.
- تحقق مما إذا كنت تستخدم أحدث إصدار من البرنامج والتوقيع الملفات.
- قراءة الوثائق. قد تكون هناك إجابات هناك.
- قراءة صفحة المشكلات. قد تكون هناك إجابات هناك.
- لا يوجد حتى الآن إجابات؟ يرجى طلب المساعدة عبر صفحة القضايا.
CIDRAM يمكن أن تتوقف حركة المرور غير المرغوب فيها، ولكن اصحاب المواقع هي المسؤولة عن البت في كيفية استخدام هذه. ويمكننا تصحيح أخطائنا، ولكن في حالات أخرى، ستحتاج إلى الاتصال بأصحاب الموقع ذات الصلة. لا نستطيع أن نفعل أي شيء عن أشياء خارجة عن سيطرتنا.
لا. PHP≥7.2 هو الحد الأدنى لمتطلبات CIDRAM v3.
نعم. يمكن استخدام CIDRAM لحماية نطاقات متعددة. إذا كان التكوين المطلوب مختلفا، للقيام بذلك، إنشاء ملفات تكوين جديدة، واسمه وفقا للنطاقات التي تتطلب الحماية. كمثال، ل
"https://www.some-domain.tld/"، أطلق عليه اسما "some-domain.tld.config.yml". اسم النطاق يأتي من "HTTP_HOST". يتم تجاهل "www".ربما. وينظر في ذلك على أساس كل حالة على حدة. أخبرنا احتياجاتك وما تقدمه. سنخبرك بما إذا كنا نستطيع مساعدتك أم لا.
راجع اإلجابة أعاله.
راجع اإلجابة أعاله.
نعم. ترخيصنا لا يحظر هذا.
نعم. المساهمة في المشروع هو موضع ترحيب كبير. يرجى الاطلاع على "CONTRIBUTING.md" لمزيد من المعلومات.
نعم. يتم تضمين API في front-end للتفاعل مع صفحة التحديثات عبر النصوص البرمجية الخارجية. وهناك نص منفصل، Cronable، هو متاح، ويمكن استخدامها من قبل مدير كرون أو كرون جدولة لتحديث هذا وغيرها من الحزم المعتمدة تلقائيا (يوفر هذا البرنامج النصي وثائقه الخاصة).
يرتبط "عدد التوقيعات" و "المخالفات" بخطورة وعدد التوقيعات التي تم إطلاقها أثناء أي طلب معين، سواء كان ذلك بسبب ملفات التوقيع أو الوحدات النمطية أو القواعد المساعدة أو غير ذلك. ولكن، بينما يستمر "عدد التوقيعات" فقط لهذا الطلب بعينه، يمكن أن تستمر "المخالفات" في العديد من الطلبات كما هو محدد بواسطة
default_tracktime.وهذا يضمن أنه عندما يتم حظر طلب بعدد كافٍ من المخالفات، يمكن أيضًا حظر الطلبات اللاحقة من نفس المصدر.
نعم. يمكن تحقيق ذلك عن طريق إنشاء قاعدة مساعدة أو وحدة مخصصة.
| IP | المشغل |
|---|---|
1.1.1.1 |
Cloudflare |
8.8.4.48.8.8.82001:4860:4860::88442001:4860:4860::8888 |
Google Public DNS |
9.9.9.9149.112.112.112 |
Quad9 DNS |
84.200.69.8084.200.70.402001:1608:10:25::1c04:b12f2001:1608:10:25::9249:d69b |
DNS.WATCH |
208.67.220.220208.67.222.220208.67.222.222 |
OpenDNS Home |
77.88.8.177.88.8.82a02:6b8::feed:0ff2a02:6b8:0:1::feed:0ff |
Yandex.DNS |
8.20.247.208.26.56.26 |
Comodo Secure DNS |
216.146.35.35216.146.36.36 |
Dyn |
64.6.64.664.6.65.6 |
Verisign Public DNS |
37.235.1.17437.235.1.17745.33.97.5172.104.237.57172.104.49.100 |
FreeDNS |
156.154.70.1156.154.71.12610:a1:1018::12610:a1:1019::1 |
Neustar Security |
45.32.36.3645.77.165.194 |
Fourth Estate |
74.82.42.42 |
Hurricane Electric |
195.46.39.39195.46.39.40 |
SafeDNS |
89.233.43.7191.239.100.100 2001:67c:28a4::2a01:3a0:53:53:: |
UncensoredDNS |
208.76.50.50208.76.51.51 |
SmartViper |
ملحوظة: لا أقدم أي مطالبات أو ضمانات بشأن ممارسات الخصوصية والأمن والفعالية ولا موثوقية أي خدمات DNS، المدرجة أو غير ذلك. يرجى إجراء البحوث الخاصة بك عند اتخاذ القرارات بشأنها.
يمكنك (من الناحية القانونية)، ولكن لا ينبغي (من الناحية الفنية؛ من الناحية العملية). ترخيصنا لا يحد من التقنيات التي تنفذ CIDRAM، لكن CIDRAM عبارة عن WAF (تطبيق ويب جدار حماية) وكان الهدف منه حماية مواقع الويب دائمًا. نظرًا لأنه لم يتم تصميمه مع وضع التقنيات الأخرى في الاعتبار، فمن غير المحتمل أن تكون فعالة أو توفر حماية موثوقة للتكنولوجيات الأخرى، ومن المرجح أن يكون التنفيذ صعباً، وأن خطر التعرض للإيجابيات الخاطئة والكشف عن الأخطاء يكون عالياً جداً.
ربما. يعتمد هذا على طبيعة الخدمة المعنية وكيفية استخدامك لها. بشكل عام، إذا كنت تقوم فقط بالتخزين المؤقت لأصول ثابتة (الصور، CSS، إلخ؛ أي شيء لا يتغير بشكل عام بمرور الوقت)، فلا يجب أن تكون هناك أية مشكلات. قد تكون هناك مشكلات على الرغم من ذلك، إذا كنت تقوم بتخزين البيانات في ذاكرة التخزين المؤقت التي عادة ما يتم إنشاؤها بشكل ديناميكي عند طلبها، أو إذا كنت تخبئ نتائج طلبات POST مؤقتًا (هذا من شأنه أن يجعل موقعك على الويب وبيئته ثابتًا تمامًا، ومن غير المرجح أن يوفر CIDRAM أي فائدة ذات معنى في بيئة ساكنة تمامًا). قد يكون هناك أيضًا متطلبات تهيئة محددة لـ CIDRAM، بناءً على نوع CDN أو خدمة التخزين المؤقت التي تستخدمها (ستحتاج إلى التأكد من تكوين CIDRAM بشكل صحيح لـ CDN أو خدمة التخزين المؤقت التي تستخدمها). قد يؤدي الفشل في تكوين CIDRAM بشكل صحيح إلى وجود إشكاليات خاطئة معضلة إلى حد كبير وعمليات الكشف المفقودة.
إجابة مختصرة: لا.
بتفاصيل اكثر: سيساعد CIDRAM في الحد من تأثير حركة المرور غير المرغوب فيها على موقعك على الويب (وبالتالي تقليل تكاليف النطاق الترددي لموقع الويب الخاص بك)، وعلى أجهزتك (على سبيل المثال، قدرة الخادم على معالجة الطلبات وتقديمها)، ويمكن أن يساعد على تقليل مختلف الآثار السلبية المحتملة المرتبطة بالزيارات غير المرغوب فيها. ومع ذلك، هناك أمران مهمان يجب تذكرهما لفهم هذا السؤال.
أولا، CIDRAM هي حزمة PHP، وبالتالي تعمل في الجهاز حيث يتم تثبيت PHP. وهذا يعني أن CIDRAM يمكنه فقط رؤية طلب ما وحظره بعد استلام الخادم له بالفعل. ثانيًا، يجب أن يعمل تخفيف DDoS الفعال على تصفية الطلبات قبل أن تصل إلى الخادم المستهدف بهجوم DDoS. من الناحية المثالية، يجب اكتشاف هجمات DDoS وتخفيفها بواسطة حلول قادرة على إسقاط أو إعادة توجيه حركة المرور المرتبطة بالهجمات، قبل أن تصل إلى الخادم المستهدف في المقام الأول.
ويمكن تنفيذ ذلك باستخدام حلول الأجهزة المخصصة، والحلول القائمة على السحابة مثل خدمات التخفيف المخصصة لخدمة DDoS، وتوجيه DNS الخاص بالنطاق من خلال شبكات مقاومة DDoS، والترشيح المستند إلى السحابة، أو مزيج من ذلك. على أي حال، فإن هذا الموضوع معقد بعض الشىء بحيث لا يمكن تفسيره بشكل كامل مع مجرد فقرة أو فقرتين، لذا أوصي بإجراء المزيد من الأبحاث إذا كان هذا موضوعًا تريد دراسته. عندما يتم فهم الطبيعة الحقيقية لهجمات DDoS بشكل صحيح، فإن هذا الجواب سيكون أكثر منطقية.
نعم. إذا كنت بحاجة إلى فرض بعض الملفات للتنفيذ بترتيب معين، فيمكنك إضافة بعض البيانات الاعتباطية قبل أسمائها في توجيه التهيئة حيث يتم إدراجها، مفصولة بنقطتين. عندما تقوم صفحة التحديثات بفرز الملفات في وقت لاحق، ستؤثر هذه البيانات العشوائية المضافة على ترتيب الفرز، مما يؤدي إلى تنفيذها وفقًا للترتيب الذي تريده، دون الحاجة إلى إعادة تسمية أي منها.
على سبيل المثال، بافتراض توجيه تكوين مع الملفات المسرودة كما يلي:
modules: |
file1.php
file2.php
file3.php
file4.php
file5.phpإذا كنت تريد
file3.php تنفيذ أولاً، يمكنك إضافة شيء مثل aaa: قبل اسم الملف:modules: |
file1.php
file2.php
aaa:file3.php
file4.php
file5.phpوبعد ذلك، إذا تم تنشيط ملف جديد،
file6.php، فعندما تقوم صفحة التحديثات بفرزها مرة أخرى، يجب أن ينتهي الأمر بهذا الشكل:modules: |
aaa:file3.php
file1.php
file2.php
file4.php
file5.php
file6.phpنفس الموقف عندما يتم إلغاء تنشيط الملف. وبالعكس، إذا أردت تنفيذ الملف آخر، فيمكنك إضافة شيء مثل
zzz: قبل اسم الملف. على أي حال، لن تحتاج إلى إعادة تسمية الملف المعني."PDO" هو اختصار لـ "PHP Data Objects" (كائنات بيانات PHP). يوفر واجهة لـ PHP لتكون قادرة على الاتصال ببعض أنظمة قواعد البيانات التي يشيع استخدامها في مختلف تطبيقات PHP.
"DSN" هو اختصار لـ "data source name" (اسم مصدر البيانات). يصف "PDO DSN" لـ PDO كيف يجب أن تتصل بقاعدة بيانات.
يوفر CIDRAM خيار استخدام PDO لأغراض التخزين المؤقت. من أجل هذا للعمل بشكل صحيح، ستحتاج إلى تكوين CIDRAM وفقًا لذلك، وتمكين PDO، وإنشاء قاعدة بيانات جديدة لاستخدام لCIDRAM (إذا لم يكن لديك بالفعل قاعدة بيانات لاستخدام لCIDRAM)، وإنشاء جدول جديد في قاعدة البيانات الخاصة بك بما يتوافق مع الهيكل الموصوف أدناه.
عندما يكون اتصال قاعدة البيانات بنجاح، لكن الجدول الضروري غير موجود، فسيحاول إنشاؤه تلقائيًا. ومع ذلك، لم يتم اختبار هذا السلوك على نطاق واسع ولا يمكن ضمان النجاح.
هذا، بالطبع، ينطبق فقط إذا كنت تريد بالفعل أن تستخدم PDO لCIDRAM. إذا كنت سعيدًا بدرجة كافية لاستخدام التخزين المؤقت للملفات (وفقًا للتهيئة الافتراضية لـ CIDRAM)، أو أي من خيارات التخزين المؤقت الأخرى المتوفرة، فلن تحتاج إلى متاعب نفسك في إعداد قواعد البيانات والجداول.
يستخدم الهيكل الموصوف أدناه "cidram" كاسم قاعدة البيانات الخاصة به، ولكن يمكنك استخدام أي اسم تريده لقاعدة البيانات الخاصة بك، طالما يتم نسخ نفس الاسم في تكوين DSN الخاص بك.
╔══════════════════════════════════════════════╗
║ DATABASE "cidram" ║
║ │╔═══════════════════════════════════════════╩═════╗
║ └╫─TABLE "Cache" (UTF-8) ║
║ ╠═╪═FIELD══CHARSET═DATATYPE═════KEY══NULL═DEFAULT═╣
║ ║ ├─"Key"──UTF-8───VARCHAR(128)─PRI──×────× ║
║ ║ ├─"Data"─UTF-8───TEXT─────────×────×────× ║
╚══╣ └─"Time"─×───────INT(>=10)────×────×────× ║
╚═════════════════════════════════════════════════╝
يجب تكوين توجيه التكوين
pdo_dsn الخاص بـ CIDRAM كما هو موضح أدناه.اعتمادًا على برنامج تشغيل قاعدة البيانات المستخدم...
├─4d (تحذير: تجريبي، لم يتم اختباره، غير مستحسن)
│ │
│ │ ╔═══════╗
│ └─4D:host=localhost;charset=UTF-8
│ ╚╤══════╝
│ └المضيف للاتصال مع للعثور على قاعدة البيانات
├─cubrid
│ │
│ │ ╔═══════╗ ╔═══╗ ╔═════╗
│ └─cubrid:host=localhost;port=33000;dbname=example
│ ╚╤══════╝ ╚╤══╝ ╚╤════╝
│ │ │ └اسم قاعدة البيانات المراد استخدامها
│ │ │
│ │ └رقم المنفذ للاتصال بالمضيف مع
│ │
│ └المضيف للاتصال مع للعثور على قاعدة البيانات
├─dblib
│ │
│ │ ╔═══╗ ╔═══════╗ ╔═════╗
│ └─dblib:host=localhost;dbname=example
│ ╚╤══╝ ╚╤══════╝ ╚╤════╝
│ │ │ └اسم قاعدة البيانات المراد استخدامها
│ │ │
│ │ └المضيف للاتصال مع للعثور على قاعدة البيانات
│ │
│ └"mssql", "sybase", "dblib": القيم الممكنة
├─firebird
│ │
│ │ ╔═══════════════════╗
│ └─firebird:dbname=/path/to/database.fdb
│ ╚╤══════════════════╝
│ ├يمكن أن يكون الطريق إلى ملف قاعدة البيانات المحلية
│ │
│ ├يمكن الاتصال مع المضيف ورقم المنفذ
│ │
│ └يجب عليك الرجوع إلى وثائق Firebird إذا كنت تريد استخدام هذا
├─ibm
│ │
│ │ ╔═════╗
│ └─ibm:DSN=example
│ ╚╤════╝
│ └التي فهرستها قاعدة البيانات للتواصل مع
├─informix
│ │
│ │ ╔═════╗
│ └─informix:DSN=example
│ ╚╤════╝
│ └التي فهرستها قاعدة البيانات للتواصل مع
├─mysql (الأكثر الموصى بها)
│ │
│ │ ╔═════╗ ╔═══════╗ ╔══╗
│ └─mysql:dbname=example;host=localhost;port=3306
│ ╚╤════╝ ╚╤══════╝ ╚╤═╝
│ │ │ └رقم المنفذ للاتصال بالمضيف مع
│ │ │
│ │ └المضيف للاتصال مع للعثور على قاعدة البيانات
│ │
│ └اسم قاعدة البيانات المراد استخدامها
├─oci
│ │
│ │ ╔═════╗
│ └─oci:dbname=example
│ ╚╤════╝
│ ├يمكن الرجوع إلى قاعدة البيانات المفهرسة المحددة
│ │
│ ├يمكن الاتصال مع المضيف ورقم المنفذ
│ │
│ └يجب عليك الرجوع إلى وثائق Oracle إذا كنت تريد استخدام هذا
├─odbc
│ │
│ │ ╔═════╗
│ └─odbc:example
│ ╚╤════╝
│ ├يمكن الرجوع إلى قاعدة البيانات المفهرسة المحددة
│ │
│ ├يمكن الاتصال مع المضيف ورقم المنفذ
│ │
│ └└يجب عليك الرجوع إلى وثائق ODBC/DB2 إذا كنت تريد استخدام هذا
├─pgsql
│ │
│ │ ╔═══════╗ ╔══╗ ╔═════╗
│ └─pgsql:host=localhost;port=5432;dbname=example
│ ╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ │ └اسم قاعدة البيانات المراد استخدامها
│ │ │
│ │ └رقم المنفذ للاتصال بالمضيف مع
│ │
│ └المضيف للاتصال مع للعثور على قاعدة البيانات
├─sqlite
│ │
│ │ ╔════════╗
│ └─sqlite:example.db
│ ╚╤═══════╝
│ └المسار إلى ملف قاعدة البيانات المحلية للاستخدام
└─sqlsrv
│
│ ╔═══════╗ ╔══╗ ╔═════╗
└─sqlsrv:Server=localhost,1521;Database=example
╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ └اسم قاعدة البيانات المراد استخدامها
│ │
│ └رقم المنفذ للاتصال بالمضيف مع
│
└المضيف للاتصال مع للعثور على قاعدة البيانات
إذا لم تكن متأكدًا مما يمكنك استخدامه في جزء معين من DSN، فحاول أولاً معرفة ما إذا كان يعمل كما هو، دون تغيير أي شيء.
لاحظ أن
pdo_username و pdo_password يجب أن يكونا نفس اسم المستخدم وكلمة المرور اللذين اخترتهما لقاعدة بياناتك.إذا كنت تستخدم ملفًا مخصصًا لأغراض cronjobs، وإذا لم يكن من الضروري استدعاء هذا الملف أثناء طلبات المستخدم العادية (بمعنى، خارج سياق cronjobs)، تتمثل الطريقة الأكثر مباشرة لإصلاح ذلك في ضمان عدم تنفيذ CIDRAM على الإطلاق خلال cronjobs الخاص بك (بمعنى، لا تقم بتوصيل CIDRAM بالملف المسؤول عن معالجة cronjobs الخاص بك).
بدلا من ذلك، إذا كان هذا غير ممكن، لكن عنوان IP الخاص بخادم cron ثابت نسبيًا ويمكن التنبؤ به، يمكنك محاولة إدراج عنوان IP لخادم cron في القائمة البيضاء، عن طريق إنشاء توقيع في القائمة البيضاء في ملف توقيع مخصص، أو عن طريق إنشاء قاعدة مساعدة لإدراجها في القائمة البيضاء. إذا كان عنوان IP لخادم cron يتغير بانتظام ولا يمكن التنبؤ به بشكل خاص، ولكن مع ذلك يبقى من داخل نفس الشبكة الخاصة، يمكنك محاولة إدراج اسم قسم التوقيع المسؤول عن حظره في المقام الأول في ملف
ignore.dat.إذا جربت كل هذه الأفكار ولم يعمل أي منها معك، أو إذا كنت بحاجة إلى مساعدة لمعرفة كيفية القيام بذلك، يمكنك إنشاء issue جديدة في صفحة issues CIDRAM لطلب المساعدة.
يصف هذا القسم من الوثائق الاعتبارات القانونية الممكنة فيما يتعلق باستخدام الحزمة وتنفيذها، ويوفر بعض المعلومات الأساسية ذات الصلة. قد يكون هذا مهمًا لبعض المستخدمين كوسيلة لضمان التوافق مع أي متطلبات قانونية قد تكون موجودة في البلدان التي يعملون فيها، وقد يحتاج بعض المستخدمين إلى تعديل سياسات موقع الويب الخاصة بهم وفقًا لهذه المعلومات.
أولا، يرجى ندرك أنني (مؤلف حزمة) لست محام، وليس أي نوع من المهنيين القانونيين المؤهلين. لذلك، لست مؤهلاً قانونًا لتقديم المشورة القانونية. أيضا، في بعض الحالات، قد تختلف المتطلبات القانونية بين الدول والاختصاصات المختلفة، وهذه المتطلبات القانونية المتفاوتة قد تكون متناقضة في بعض الأحيان (على سبيل المثال، الدول التي تفضل "حقوق الخصوصية" و "الحق في أن تنسى"، مقارنة بالبلدان التي تفضل "الاحتفاظ بالبيانات"). ضع في اعتبارك أيضًا أن الوصول إلى الحزمة لا يقتصر على بلدان أو ولايات قضائية محددة، وبالتالي، فإن مستخدمي الحزمة من المحتمل أن يكونوا متنوعين جغرافيًا. بالنظر إلى هذه النقاط، فأنا لست في وضع يسمح لي بالإشارة إلى ما يعنيه أن يكون "متوافقة مع القانون" مع الجميع. ومع ذلك، آمل أن تساعدك هذه المعلومات على أن تقرر بنفسك ما يجب عليك القيام به للبقاء ملتزمين قانونًا في سياق الحزمة. إذا كانت لديك أي شكوك بخصوص هذه المعلومات، أو إذا كنت بحاجة إلى مساعدة ومشورة إضافية من منظور قانوني، فإنني أوصيك باستشارة متخصص قانوني مؤهل.
كما هو مذكور بالفعل من قبل ترخيص الحزمة، يتم توفير الحزمة دون أي ضمان. وهذا يشمل (على سبيل المثال لا الحصر) كل نطاق المسؤولية. يتم توفير الحزمة لك لراحتك، على أمل أن تكون مفيدة، وأنها سوف توفر بعض الفائدة بالنسبة لك. ومع ذلك، سواء كنت تستخدم أو تنفذ الحزمة، فذلك هو خيارك. لا تضطر إلى استخدام الحزمة أو تنفيذها، ولكن عندما تقوم بذلك، فأنت مسؤول عن هذا القرار. لا أنا ولا أي مساهم آخر في الحزمة مسؤول قانونيًا عن عواقب القرارات التي تتخذها، بصرف النظر عما إذا كانت مباشرة أو غير مباشرة أو ضمنية أو غير ذلك.
اعتمادا على التكوين الدقيق والتنفيذ، قد تتواصل الحزمة وتتبادل المعلومات مع أطراف ثالثة في بعض الحالات. في بعض السياقات، من خلال بعض السلطات القضائية، يمكن تعريف ذلك على أنه "معلومات تعريف شخصية".
إن كيفية استخدام هذه المعلومات من قِبل هذه الجهات الخارجية تخضع لسياساتها، وهي خارج نطاق هذه الوثائق. ومع ذلك، في جميع هذه الحالات، يمكن تعطيل مشاركة المعلومات. في جميع هذه الحالات، إذا اخترت تمكينها، تقع على عاتقك مسؤولية البحث عن أي مخاوف قد تكون لديك بشأن الخصوصية والأمان واستخدام هذه المعلومات من قِبل هذه الأطراف الثالثة. إذا وجدت أي شكوك، أو إذا كنت غير راضي عن سلوك هذه الأطراف الثالثة، قد يكون من الأفضل تعطيل كل مشاركة المعلومات مع هذه الأطراف الثالثة.
لغرض الشفافية، يتم وصف نوع المعلومات المشتركة أدناه.
إذا كنت تستخدم أي ميزات أو وحدات تهدف إلى العمل مع أسماء المضيفين، فيجب أن يكون CIDRAM قادرًا على الحصول على اسم المضيف للطلبات الواردة. عادة، تقوم بذلك عن طريق طلب أسماء المضيف لعنوان IP من خادم DNS، أو عن طريق طلب المعلومات من خلال الوظائف التي يوفرها النظام مباشرة. تنتمي خوادم DNS المحددة افتراضيًا إلى خدمة Google DNS (ولكن هذا يمكن تغييره بسهولة عبر التكوين). يمكن تكوين الخدمات الدقيقة التي يتم الاتصال بها، وتعتمد على كيفية تكوين الحزمة. عند طلب ذلك عبر النظام مباشرة، ستحتاج إلى الاتصال بمسؤول النظام لتحديد الطرق المستخدمة. يمكن منع عمليات البحث عن اسم المضيف في CIDRAM عن طريق تجنب الوحدات المتأثرة أو عن طريق تعديل تكوين الحزمة وفقًا لذلك.
خيارات التكوين ذات الصلة:
allow_gethostbyaddr_lookup<-generaldefault_dns<-generalforce_hostname_lookup<-generalother<-verificationsearch_engines<-verificationsocial_media<-verification
عندما يتم تمكين هذه الخيارات، يحاول CIDRAM التحقق من صحة الطلبات من محركات البحث والشبكات الاجتماعية. للقيام بذلك، فإنه يستخدم خدمة Google DNS لمحاولة حل عناوين IP من أسماء المضيفين لهذه الطلبات الواردة (في هذه العملية، تتم مشاركة أسماء المضيفين لهذه الطلبات الواردة مع الخدمة).
خيارات التكوين ذات الصلة:
other<-verificationsearch_engines<-verificationsocial_media<-verification
يتم دعم reCAPTCHA و hCAPTCHA بواسطة CIDRAM. تتطلب مفاتيح API لكي تعمل بشكل صحيح. يتم تعطيلها افتراضيًا، ولكن يمكن تمكينها عن طريق تكوين مفاتيح واجهة برمجة التطبيقات المطلوبة. عند التمكين، قد يحدث اتصال بين الخدمة و CIDRAM أو متصفح المستخدم. قد يتضمن ذلك نقل معلومات مثل عنوان IP للمستخدم ووكيل المستخدم ونظام التشغيل.
Stop Forum Spam هي خدمة رائعة متاحة مجانًا يمكن أن تساعد في حماية المنتديات والمدونات ومواقع الويب من مرسلي الرسائل غير المرغوب فيها. ويقوم بذلك عن طريق توفير قاعدة بيانات لمعرّفي البريد المزعوم المعروفين وواجهة برمجة تطبيقات يمكن الاستفادة منها للتحقق مما إذا كان عنوان IP أو اسم المستخدم أو عنوان البريد الإلكتروني مدرجًا في قاعدة البيانات الخاصة به.
يوفر CIDRAM المكون اختيارية تستفيد من واجهة برمجة التطبيقات هذه للتحقق مما إذا كان عنوان IP للطلبات الواردة ينتمي إلى مرسلي بريد مزعوم مشتبه فيهم. عندما يتم تثبيت الوحدة وتنشيطها، فقد تتم مشاركة عناوين IP الخاصة بالمستخدمين مع الخدمة وفقًا للتكوين والغرض المقصود من الوحدة.
يوفر CIDRAM المكون نمطية اختيارية لحظر عناوين IP المسيئة باستخدام واجهة برمجة تطبيقات AbuseIPDB. عندما يتم تثبيت الوحدة وتنشيطها، فقد تتم مشاركة عناوين IP الخاصة بالمستخدمين مع الخدمة وفقًا للتكوين والغرض المقصود من الوحدة.
يوفر CIDRAM المكون نمطية اختيارية لإجراء عمليات البحث ASN ورمز البلد باستخدام API BGPView وAPI IP-API. توفر عمليات البحث هذه القدرة على حظر أو إدراج طلبات القائمة البيضاء على أساس ASN أو بلد المنشأ. عندما يتم تثبيت الوحدة وتنشيطها، فقد تتم مشاركة عناوين IP الخاصة بالمستخدمين مع الخدمة وفقًا للتكوين والغرض المقصود من الوحدة.
يوفر CIDRAM المكون نمطية اختيارية لحظر عناوين IP المسيئة باستخدام واجهة برمجة تطبيقات Project Honeypot. عندما يتم تثبيت الوحدة وتنشيطها، فقد تتم مشاركة عناوين IP الخاصة بالمستخدمين مع الخدمة وفقًا للتكوين والغرض المقصود من الوحدة.
التسجيل هو جزء مهم من CIDRAM لعدد من الأسباب. قد يكون من الصعب تشخيص وحل إيجابيات خاطئة عندما لا يتم تسجيل أحداث الحظر التي تسبب لهم. بدون تسجيل أحداث الحظر، قد يكون من الصعب التأكد من أداء CIDRAM بشكل جيد، وقد يكون من الصعب تحديد مواطن ضعفها، وما هي التغييرات التي قد تكون مطلوبة لتكوينها أو توقيعاتها، لكي تستمر في العمل على النحو المنشود. بغض النظر، ربما لا يريد الجميع التسجيل، لذلك يبقى اختياريًا تمامًا. في CIDRAM، يتم تعطيل التسجيل افتراضيًا. لتمكينه، يجب تكوين CIDRAM وفقًا لذلك.
بالإضافة إلى، ما إذا كان تخزين هذا النوع من البياناتمسموحًا به قانونًا، وإلى الحد المسموح به قانونًا (ذلك بالقول، أنواع المعلومات التي يمكن تسجيلها، إلى متى، وتحت أي ظروف)، قد تختلف، وهذا يتوقف على الاختصاص واعتمادًا على سياق التنفيذ (فمثلا، سواء كنت تعمل كفرد أو مؤسسة، وعما إذا كان ذلك على أساس تجاري أو غير تجاري). لذلك قد يكون من المفيد لك قراءة هذا القسم بعناية.
هناك العديد من أنواع المعلومات المختلفة التي يمكن تسجيلها، لأسباب مختلفة.
النوع الأساسي من التسجيل الذي يمكن أن يؤديه CIDRAM يتعلق بـ "حظر الأحداث". يتعلق هذا عندما يقوم CIDRAM بحظر الطلب، ويمكن توفيره في ثلاثة تنسيقات مختلفة:
- السجلات التي يمكن قراءتها من قبل البشر.
- سجلات في اسلوب اباتشي.
- سجلات مسلسلة.
حدث كتلة، سجلت إلى ملف سجل الإنسان مقروء، يبدو عادة مثل هذا (على سبيل المثال):
الهوية الشخصية:1234النسخة النصية:CIDRAM v1.6.0الوقت/التاريخ:Day, dd Mon 20xx hh:ii:ss +0000عنوان IP:x.x.x.xاسم المضيف:dns.hostname.tldعدد التوقيعات:1مرجع التوقيعات:x.x.x.x/xxسبب الحظر: الخدمات السحابية ("اسم الشبكة",Lxx:Fx,[XX])! وكيل المستخدم:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36أعيد بناؤها URI:https://your-site.tld/index.phpالحالة CAPTCHA: تمكين.
نفس الشيء، المسجل في ملف السجل على نمط Apache، سيبدو كالتالي:
x.x.x.x - - [Day, dd Mon 20xx hh:ii:ss +0000] "GET /index.php HTTP/1.1" 200 xxxx "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36"
عادةً ما يتضمن إدخال سجل أحداث الحظر المعلومات التالية:
- رقم ID يشير إلى الحدث.
- إصدار CIDRAM قيد الاستخدام حاليًا.
- تاريخ ووقت وقوع الحدث.
- عنوان IP الخاص بالطلب المحظور.
- اسم المضيف لعنوان IP الخاص بالطلب المحظور (عندما يكون متاحًا).
- عدد التوقيعات التي أثارها الطلب.
- المراجع إلى التوقيعات أثار.
- تشير إلى أسباب الحدث وبعض المعلومات الأساسية المتعلقة بالتصحيح.
- وكيل المستخدم للطلب المحظور (أي كيف حدد الكيان الذي أرسل الطلب نفسه).
- إعادة بناء معرف المورد.
- حالة CAPTCHA للطلب الحالي (عند الضرورة).
توجيهات التهيئة ذات الصلة:
apache_style_log<-loggingserialised_log<-loggingstandard_log<-logging
عندما يتم ترك هذه التوجيهات فارغة، سيظل هذا النوع من التسجيل معطلاً.
هذا النوع من التسجيل يتعلق بشكل خاص بمثيلات CAPTCHA. يحدث فقط عندما يحاول مستخدم لإكمال CAPTCHA.
يحتوي إدخال سجل CAPTCHA على عنوان IP الخاص بالمستخدم الذي يحاول إكمال CAPTCHA، وتاريخ ووقت حدوث المحاولة، وحالة CAPTCHA. عادةً ما تبدو الإدخالات كما يلي (كمثال):
عنوان IP: x.x.x.x - الوقت/التاريخ: Day, dd Mon 20xx hh:ii:ss +0000 - الحالة CAPTCHA: نجحت!
توجيه التكوين ذات الصلة:
hcaptcha_log<-hcaptcharecaptcha_log<-recaptcha
هذا التسجيل يتصل محاولات تسجيل الدخول الأمامية. يحدث فقط عندما يحاول مستخدم تسجيل الدخول إلى الواجهة الأمامية، وفقط عندما يتم تمكين الوصول للجهة الأمامية.
يحتوي إدخال سجل الواجهة الأمامية على عنوان IP الخاص بالمستخدم الذي يحاول تسجيل الدخول وتاريخ ووقت حدوث المحاولة ونتائج المحاولة (تم تسجيل الدخول بنجاح، أو فشل في تسجيل الدخول). يبدو عادة مثل هذا (كمثال):
x.x.x.x - Day, dd Mon 20xx hh:ii:ss +0000 - "admin" - حاليا على.
توجيه التكوين ذات الصلة:
frontend_log<-frontend
قد ترغب في تطهير السجلات بعد فترة من الوقت، أو قد تكون مطلوبة للقيام بذلك بموجب القانون (أي أن مقدار الوقت المسموح به قانونًا لك للاحتفاظ بالسجلات قد يكون محدودًا بموجب القانون). يمكنك تحقيق ذلك عن طريق تضمين علامات التاريخ/الوقت في أسماء ملفات السجل الخاصة بك كما هو محدد بواسطة تكوين الحزمة الخاصة بك (على سبيل المثال،
{yyyy}-{mm}-{dd}.log)، ثم تمكين دوران السجل (يسمح لك تدوير السجل بتنفيذ بعض الإجراءات على ملفات السجل عندما يتم تجاوز الحدود المحددة).فمثلا: إذا كان من الضروري قانونًا حذف السجلات بعد 30 يومًا، يمكنني تحديد
{dd}.log في أسماء ملفات السجل الخاصة بي ({dd} يمثل عدد الأيام)، قم بتعيين قيمة log_rotation_limit إلى 30، وقم بتعيين قيمة log_rotation_action إلى Delete.على العكس من ذلك، إذا كنت مطالبًا بالاحتفاظ بالسجلات لفترة زمنية طويلة، فيمكنك تعطيل تدوير السجل، أو يمكنك تعيين قيمة
log_rotation_action إلى Archive، لضغط ملفات السجل، وبالتالي تقليل إجمالي مساحة القرص التي يشغلونها.خيارات التكوين ذات الصلة:
log_rotation_action<-logginglog_rotation_limit<-logging
إذا أردت، يمكنك اقتطاع ملفات السجل الفردية عندما تتجاوز حجمًا معينًا.
خيارات التكوين ذات الصلة:
truncate<-logging
أولاً، إذا لم تكن على دراية بهذا المصطلح، "pseudonymisation" يشير إلى معالجة البيانات الشخصية على هذا النحو بحيث لا يمكن تحديدها لأي موضوع بيانات محدد بعد الآن بدون معلومات إضافية، وشريطة أن يتم الاحتفاظ بهذه المعلومات التكميلية بشكل منفصل وتخضع للتدابير التقنية والتنظيمية لضمان عدم إمكانية تحديد البيانات الشخصية لأي شخص طبيعي.
يمكن أن تساعد الموارد التالية في شرحها بمزيد من التفاصيل:
في بعض الحالات، قد يُطلب منك قانونًا تنفيذ "anonymisation" أو "pseudonymisation" لأي معلومات PII تم جمعها أو معالجتها أو تخزينها. على الرغم من وجود هذا المفهوم منذ بعض الوقت، GDPR/DSGVO يذكر بشكل ملحوظ ويشجع "pseudonymisation".
إذا أردت، يمكن لـ CIDRAM القيام بذلك لعناوين IP عند الكتابة إلى السجلات. عند الكتابة إلى السجلات، سيتم تمثيل الثمانية النهائية لعناوين IPv4 وكل شيء بعد الجزء الثاني من عناوين IPv6 بواسطة "x" (تقريب عناوين IPv4 إلى العنوان الأولي للشبكة الفرعية الـ 24 التي تدخلها، وعناوين IPv6 إلى العنوان الأولي للشبكة الفرعية 32 التي تدخلها).
ملحوظة: ميزة تتبع IP من CIDRAM لا تملك هذه القدرة. إذا كانت هذه مشكلة بالنسبة لك، فقد يكون من الأفضل تعطيل تتبع IP بالكامل.
خيارات التكوين ذات الصلة:
pseudonymise_ip_addresses<-legal
إذا كنت ترغب في منع تسجيل أنواع معينة من المعلومات بالكامل، فيمكنك القيام بذلك. في صفحة التكوين، يرجى الرجوع إلى توجيه تكوين
fields للتحكم في الحقول التي تظهر في إدخالات السجل وفي صفحة "تم رفض الوصول".
ملحوظة: لا يوجد سبب لاستخدام pseudonymisation لعناوين IP عند حذف عناوين IP من السجلات بالكامل.
خيارات التكوين ذات الصلة:
fields<-general
CIDRAM قادر بشكل اختياري على تتبع الإحصائيات مثل إجمالي عدد أحداث المنع أو حالات CAPTCHA التي حدثت منذ وقت معين. يتم تعطيل هذه الميزة بشكل افتراضي، ولكن يمكن تمكينها من خلال تهيئة الحزمة. هذه الميزة لا تتبع سوى العدد الإجمالي للأحداث. لا يتضمن أي معلومات حول أحداث معينة، لذلك لا ينبغي اعتباره معلومات تحديد الهوية الشخصية.
خيارات التكوين ذات الصلة:
statistics<-general
لا يقوم CIDRAM بتشفير ذاكرة التخزين المؤقت أو أي معلومات سجل. قد يتم إدخال تشفير ذاكرة التخزين المؤقت والسجلات في المستقبل، ولكن لا توجد خطط محددة لها حاليًا. إذا كنت قلقًا بشأن حصول أطراف ثالثة غير مصرح لها على إمكانية الوصول إلى أجزاء من CIDRAM قد تحتوي على معلومات تحديد الهوية الشخصية أو معلومات حساسة مثل ذاكرة التخزين المؤقت أو السجلات، أوصي بعدم تثبيت CIDRAM في مكان يمكن الوصول إليه بشكل عام (على سبيل المثال، مجلد تثبيت CIDRAM خارج الدليل
public_html القياسي أو ما يعادله، متاح لمعظم خوادم الويب القياسية) والتأكد من فرض الأذونات المقيدة بشكل مناسب لدليل التثبيت (على وجه الخصوص، لدليل vault). إذا لم يكن ذلك كافيًا لمعالجة مخاوفك، فقم بتكوين CIDRAM بحيث لا يتم جمع أنواع المعلومات التي تسبب مخاوفك أو تسجيلها في المقام الأول (مثل، عن طريق تعطيل التسجيل).يضع CIDRAM ملفات تعريف الارتباط في نقطتين في تعليمات البرمجة الخاصة به. أولاً، عندما يقوم المستخدم بإكمال CAPTCHA بنجاح (مع افتراض أن
lockuser مضبوطة على true)، يعيّن CIDRAM ملف تعريف ارتباط ليتمكن من التذكر للطلبات التالية بأن المستخدم قد أكمل بالفعل CAPTCHA، بحيث لا يحتاج إلى مطالبة المستخدم بإكمال CAPTCHA في الطلبات اللاحقة. ثانيا، عندما يسجل المستخدم بنجاح في الواجهة الأمامية، يعين CIDRAM ملف تعريف ارتباط حتى يتمكن من تذكر المستخدم للطلبات اللاحقة (أي، يتم استخدام ملفات تعريف الارتباط لمصادقة المستخدم على جلسة تسجيل الدخول).في كلتا الحالتين، يتم عرض تحذيرات ملفات تعريف الارتباط بشكل بارز (عند الاقتضاء)، وتحذير المستخدم من أنه سيتم تعيين ملفات تعريف الارتباط إذا شارك في الإجراءات ذات الصلة. لا يتم تعيين ملفات تعريف الارتباط في أي نقاط أخرى في مصدر التعليمات البرمجية.
ملحوظة: قد تكون واجهات برمجة تطبيقات CAPTCHA "غير المرئية" غير متوافقة مع قوانين ملفات تعريف الارتباط في بعض الولايات القضائية، ويجب تجنبها من قبل أي مواقع ويب تخضع لهذه القوانين. قد يكون من الأفضل اختيار استخدام واجهات برمجة التطبيقات الأخرى المتوفرة بدلاً من ذلك، أو ببساطة تعطيل اختبار CAPTCHA بالكامل.
خيارات التكوين ذات الصلة:
lockuser<-recaptchaapi<-recaptchalockuser<-hcaptchaapi<-hcaptcha
لا تجمع CIDRAM أو تعالج أي معلومات لأغراض التسويق أو الإعلانات، ولا تبيع أو تحقق أرباحًا من أي معلومات تم جمعها أو تسجيلها. CIDRAM ليست مؤسسة تجارية، ولا ترتبط بأي مصالح تجارية، لذا فإن القيام بهذه الأشياء لن يكون له أي معنى. كان هذا هو الحال منذ بداية المشروع، وما زالت الحالة اليوم. بالإضافة إلى ذلك، فإن القيام بهذه الأشياء سيؤدي إلى نتائج عكسية للمشروع والغرض المقصود من المشروع ككل، وطالما استمر في الحفاظ على المشروع، لن يحدث أبداً.
في بعض الحالات، قد يُطلب منك قانونًا عرض رابط لسياسة الخصوصية بوضوح في جميع صفحات وأقسام موقعك. قد يكون هذا أمرًا مهمًا كوسيلة لضمان معرفة المستخدمين جيدًا بممارسات الخصوصية الدقيقة، وأنواع معلومات تحديد الهوية الشخصية التي تجمعها، وكيفية تنوي استخدامها. لتتمكن من تضمين مثل هذا الارتباط في صفحة "تم رفض الوصول" الخاصة بـ CIDRAM، يتم توفير توجيه تكوين لتحديد عنوان URL لسياسة الخصوصية الخاصة بك.
ملحوظة: يوصى بشدة بعدم وضع صفحة سياسة الخصوصية خلف حماية CIDRAM. إذا قام CIDRAM بحماية صفحة سياسة الخصوصية الخاصة بك، وكان المستخدم المحظور من قِبل CIDRAM ينقر على رابط لسياسة الخصوصية الخاصة بك، فسيتم حظره مرة أخرى ولن يتمكن من رؤية سياسة الخصوصية الخاصة بك. من الناحية المثالية، يجب عليك الربط بنسخة ثابتة من سياسة الخصوصية، مثل صفحة HTML أو ملف نصي عادي غير محمي بواسطة CIDRAM.
خيارات التكوين ذات الصلة:
privacy_policy<-legal
يعد اللائحة العامة لحماية البيانات (GDPR) لائحة خاصة بالاتحاد الأوروبي، والتي تدخل حيز التنفيذ اعتبارًا من 25 مايو 2018. الهدف الأساسي من التنظيم هو إعطاء السيطرة على المواطنين والمقيمين في الاتحاد الأوروبي فيما يتعلق ببياناتهم الشخصية، وتوحيد الأنظمة داخل الاتحاد الأوروبي فيما يتعلق بالخصوصية والبيانات الشخصية.
تحتوي اللائحة على أحكام محددة تتعلق بمعالجة "معلومات التعريف الشخصية" لأي "موضوعات بيانات" تابعة للاتحاد الأوروبي (أي شخص طبيعي محدد أو قابل للتحديد). من أجل الامتثال للأنظمة، "الشركات" (كما هو محدد في اللائحة)، وكذلك أي أنظمة وعمليات ذات صلة، يجب تنفيذ "الخصوصية حسب التصميم" بشكل افتراضي، يجب استخدام أعلى إعدادات الخصوصية الممكنة، يجب تنفيذ الضمانات اللازمة لأية معلومات مخزنة أو معالجتها (بما في ذلك، على سبيل المثال لا الحصر، تنفيذ "pseudonymisation" أو "anonymisation" الكامل للبيانات)، يجب أن يعلن بوضوح وبشكل لا لبس فيه أنواع البيانات التي يجمعونها، كيفية معالجتها، لأي أسباب، إلى متى تحتفظ بها، وإذا شاركوا هذه البيانات مع أطراف ثالثة، وأنواع البيانات المشتركة مع أطراف ثالثة، وكيف، ولماذا، وما إلى ذلك.
لا يجوز معالجة البيانات ما لم يكن هناك أساس قانوني للقيام بذلك، كما هو محدد في اللائحة. وبشكل عام، يعني هذا أنه من أجل معالجة بيانات موضوع البيانات على أساس قانوني، يجب أن يتم ذلك وفقًا لالتزامات قانونية، أو يتم فقط بعد الحصول على موافقة واضحة ومطلعة بشكل لا لبس فيه من موضوع البيانات.
قد تتطور جوانب التنظيم في الوقت المناسب، ومن أجل تجنب نشر المعلومات القديمة، قد يكون من الأفضل معرفة التنظيم من مصدر موثوق، بدلاً من مجرد تضمين المعلومات ذات الصلة هنا في وثائق الحزمة (مثل المعلومات المضمنة قد تصبح في نهاية المطاف عفا عليها الزمن مع تطور التنظيم).
بعض الموارد الموصى بها لتعلم المزيد من المعلومات:
توجد اختلافات كبيرة بين الإصدار 3 والإصدارات الرئيسية السابقة. تختلف طريقة عمل نقاط الدخول، وطريقة تنظيم الوحدات، وطريقة عمل المحدث للإصدار 3 عن طريقة عمل هذه الأشياء للإصدارات الرئيسية السابقة. بسبب هذه الاختلافات، فإن أفضل طريقة للترقية إلى الإصدار 3 من الإصدارات الرئيسية السابقة هي إجراء تثبيت جديد.
إذا كنت تريد الاحتفاظ بالتكوين والقواعد الإضافية، فقبل بدء عملية الترقية، انتقل إلى صفحة النسخ الاحتياطي للواجهة الأمامية. من هناك، يمكن تصدير التكوين والقواعد المساعدة. سيؤدي التصدير إلى تنزيل ملف. بعد الترقية إلى الإصدار الرئيسي الجديد، يمكن استخدام هذا الملف لاستيراد البيانات التي تم تصديرها مسبقًا إلى التثبيت.
بسبب التغييرات التي تم إجراؤها على طريقة تنظيم الوحدات النمطية، يجب إعادة كتابة الوحدات المخصصة للإصدارات الرئيسية السابقة من أجل العمل بشكل صحيح مع الإصدار 3. الهجرة المباشرة لن تعمل. نفس الشيء صحيح بالنسبة للأحداث.
لم تتغير طريقة هيكلة ملفات التوقيع، لذا يمكن نقل ملفات التوقيع المخصصة للإصدارات الرئيسية السابقة مباشرة إلى الإصدار 3 دون أي مشاكل متوقعة.
تحتوي كل من الوحدات النمطية وملفات التوقيع والأحداث على أدلة مخصصة خاصة بها، وهي إضافة جديدة منذ الإصدار 3 (لذلك، بالنسبة إلى الإصدار 3، سينتقل كل منهم إلى الدلائل المخصصة له، بدلاً من جذر vault).
تم إهمال بعض ملفات التوقيع والوحدات وقوائم الحظر المتاحة للجمهور للإصدارات الرئيسية السابقة، لذلك لن يكون كل شيء متاحًا للإصدار v3. في معظم الحالات، لن تكون هناك حاجة إليها على أي حال، بسبب الميزات والوظائف الجديدة المضافة منذ الإصدار 3.
هناك بعض التغييرات الطفيفة في طريقة هيكلة القواعد المساعدة، وهناك تغييرات على التكوين، ولكن إذا كنت تستخدم ميزات الاستيراد والتصدير في صفحة النسخ الاحتياطي للواجهة الأمامية، فلن تحتاج إلى إعادة كتابة أي شيء يدويًا أو ضبطه أو إعادة إنشائه. عند الاستيراد، يعرف CIDRAM ما هو مطلوب، وسوف يتعامل معه تلقائيًا.
الإصدار 4 غير موجود بعد. ومع ذلك، عندما يحين وقت الترقية من الإصدار 3 إلى الإصدار 4، يجب أن تكون عملية الترقية أبسط بكثير. لن نعرف بالضبط مدى الاختلاف الكبير حتى يحين الوقت، لكنني أتوقع أن تكون الاختلافات أقل بكثير من ذي قبل، وقد تم بالفعل تنفيذ الآليات في الإصدار 3 منذ البداية لتسهيل عملية ترقية أكثر سلاسة. طالما لم تكن هناك تغييرات كبيرة في المحدث أو طريقة عمل نقاط الدخول، فمن المفترض، من الناحية النظرية، أن يكون من الممكن الترقية بالكامل عبر الواجهة الأمامية، دون الحاجة إلى إجراء تثبيت جديد.
سيتم تضمين المزيد من المعلومات التفصيلية هنا، في الوثائق، في وقت مناسب في المستقبل.
آخر تحديث: ٢٦ نوفمبر ٢٠٢٤ (٢٠٢٤.١١.٢٦).