Extension:AbuseFilter/ar

يسمح ملحق "AbuseFilter" للمستخدمين المتميزين بتعيين إجراءات معينة يتم اتخاذها عندما تتطابق إجراءات المستخدمين -مثل عمليات التحرير- مع معايير معينة.

على سبيل المثال، يمكن إنشاء "مُرشِّح" لمنع المستخدمين المجهولين من إضافة روابط خارجية، أو لحظر مستخدم يزيل أكثر من 2000 حرف.

الإعداد


مجموعات المستخدمين
بمجرد تثبيت الملحق، سيتعين عليك إعداد صلاحيات المستخدم في "LocalSettings.php".

على سبيل المثال، سيسمح النموذج التالي للإداريين sysops بالقيام بكل ما يريدونه باستخدام "مُرَشِّح" AbuseFilter، ويسمح للجميع بعرض السجل ومشاهدة إعدادات المُرشِّح العامة:

معاملات


الاختناق في حالات الطوارئ
يأتي AbuseFilter مزودًا بميزة تعمل تلقائيًا على تقييد (تعطيل) الفلاتر التي تم تعديلها مؤخرًا وتتوافق مع حد معين من الإجراءات الأخيرة.

يتم ذلك لمنع التعديلات الضارة على المرشحات لحظر كل مستخدم يقوم بإجراء على الويكي أو ما شابه.

يعتمد شرط تعطيل الفلتر على تلك المتغيرات:
 * - النسبة المئوية للمطابقات على المبلغ الإجمالي للإجراءات في الفترة المرصودة.
 * - عدد المطابقات للمرشح في الفترة الملاحظة.
 * - عمر المرشح لأخذه بعين الاعتبار. إذا كان التعديل الأخير للفلتر أقدم من هذا العدد من الثواني ، فلن يتم تقييد الفلتر ، إلا إذا كان قد تم تقييده بالفعل.
 * - العدد الأقصى للإجراءات الأخيرة ليتم احتسابها مقابل الحد الأدنى. لاحظ أن كل إجراء يؤدي إلى زيادة العداد ، وبمجرد وصول هذا العداد إلى هذه القيمة المكونة ، تتم إعادة تعيين هذا العداد وعدد الإجراءات الأخيرة التي تتطابق مع جميع عوامل التصفية إلى 0.

يمكن تحديد المرشحات الخانقة في قائمة المرشحات (Special: AbuseFilter) بالحالة $ 1. يحدث الاختناق بصمت ، ولا توجد طريقة لمعرفة متى يتم اختناق الفلتر.

عندما يتم تقييد أحد الفلاتر ، فإنه لا يؤدي أي إجراء خطير (عادةً ما تقتصر الإجراءات على حقوق خاصة مثل حظر المستخدم ، أو إزالته من المجموعات ، التي يتحكم فيها $wgAbuseFilterActionRestrictions) ، ولا يُسمح إلا بالإجراءات "الآمنة" (تلك التي يمكنها تحذير أو منع الإجراء المستمر). لا يتم تمكين المرشحات الخانقة تلقائيًا. لتعطيل الخنق ، تحتاج إلى تعديل عامل التصفية. لاحظ أنك تحتاج بالفعل إلى تغيير شيء ما من الفلتر: تغيير شيء ما من ملاحظات الفلتر كافٍ.

لاحظ أن تحرير الفلتر يحدّث عمره ، ويمكن أن يتسبب في تعطيله إذا وصل مرة أخرى إلى الشروط التي سيتم تقييدها في فترة قصيرة منذ التعديل الأخير ، مما يؤدي إلى عامل تصفية غير قابل للاستخدام إذا كان الويكي الخاص بك يحتوي على تعديلات إساءة استخدام أكثر من تلك الشرعية.



إنشاء وإدارة المرشحات
بمجرد تثبيت الملحق، يمكن إنشاء المرشحات /اختبارها /تغييرها /حذفها ويمكن الوصول إلى السجلات من صفحة إدارة مرشحات الإساءة Special:AbuseFilter.


 * شكل الأوامر Rules format - أساسيات كيفية كتابة مُرشِّح
 * الإجراءات Actions
 * قواعد عامة Global Rules
 * مساعدة لتقليل استخدام الشروط Guide to optimizing condition limit usage
 * To import filters from Wikipedia: When you have installed the extension, go to w:Special:AbuseFilter, choose a filter (say w:Special:AbuseFilter/3), then click "Export this filter to another wiki", copy the text, go to "Special:AbuseFilter/import" on your wiki, paste the text.
 * m:Small wiki toolkits/Starter kit/AbuseFilter - دليل لمجتمعات الويكي الصغيرة على metawiki

API
يضيف AbuseFilter وحدتين من وحدات قائمة API ، واحدة للحصول على تفاصيل عوامل تصفية إساءة الاستخدام ("عوامل تصفية إساءة الاستخدام") والأخرى لسجل إساءة الاستخدام ، نظرًا لأنها منفصلة عن سجلات MediaWiki الأخرى ("abuselog"). لا يمكن إنشاء أو تعديل عوامل تصفية إساءة الاستخدام باستخدام واجهة برمجة التطبيقات.

list = abusefilters
سرد معلومات حول عوامل التصفية


 * Parameters :
 * - معرّف عامل التصفية الذي سيبدأ التعداد منه
 * - معرّف عامل التصفية الذي سيتم إيقاف التعداد عنده
 * - الاتجاه الذي يتم فيه التعداد (أقدم ، أحدث)
 * - إظهار عوامل التصفية التي تفي بهذه المعايير فقط (مُمكّن |! مُمكّن | محذوف |! محذوف | خاص |! خاص)
 * - أقصى عدد من المرشحات لإدراجها
 * - الخصائص التي يجب الحصول عليها (المعرف | الوصف | النمط | الإجراءات | الزيارات | التعليقات | lasteditor | lastedittime | الحالة | خاصة)

عندما تكون الفلاتر خاصة ، ستفقد بعض الخصائص المحددة باستخدام  ما لم تكن لديك صلاحيات المستخدم المناسبة.


 * أمثلة:

list = abuselog
سرد الحالات التي أدت فيها الإجراءات إلى تشغيل عامل تصفية إساءة استخدام.


 * Parameters :
 * - الطابع الزمني لبدء التعداد منه
 * - الطابع الزمني لإيقاف التعداد عند
 * - الاتجاه الذي يتم فيه التعداد (أقدم ، أحدث)
 * - اعرض فقط الإدخالات التي حاول فيها مستخدم معين أو عنوان IP هذا الإجراء.
 * - اعرض فقط الإدخالات التي يتضمن الإجراء فيها صفحة معينة.
 * - اعرض فقط الإدخالات التي أدت إلى تشغيل معرّف عامل التصفية المحدد
 * - الحد الأقصى لعدد الإدخالات في القائمة
 * - الخصائص التي يجب الحصول عليها: (ids|filter|user|ip|title|action|details|result|timestamp|hidden|revid|wiki)


 * مثال:



الأخطاء المحتملة

 * قد يواجه بعض المستخدمين فشل إنشاء عوامل تصفية جديدة أو تعديل عوامل التصفية القديمة ويتم إعادة توجيه المستخدم إلى الصفحة الأصلية. إذا كان Wiki يستخدم شهادات SSL ، فمن المحتمل أن يكون هذا الخطأ بسبب قيمة $ 1 ، والتي قد تستخدم "$ 2" بدلاً من "$ 3". سيكون مؤشر هذا الخطأ هو أن المتصفح يعطي تحذيرًا بـ https لصفحات $ 1. (2 $)



دمجه مع امتدادات أخرى
You can integrate AbuseFilter with other extension in various ways.

Adding variables for filtering
It is possible to add new variables, to be used in abuse filters. A list of examples. To do that, you should:


 * Add a handler for the hook. To add a variable, you should use , where   is the name of the variable, and   is the fragment of an i18n key. The full key will be.
 * Add the i18n messages you chose at the previous point.
 * Choose a hook handler where the variable will be computed. Depending on your use case, you could:
 * Implement the hook; this is specifically thought for page-related variables;
 * Implement the hook; this is specifically thought for user-related variables;
 * Implement the hook; this is for variables not bound to a specific page or user;
 * Implement the hook; this is a bit more flexible than the other hooks, but it has a downside: your variable will not be available when examining past RecentChanges entries. If you want to implement that feature (and it's recommended to do so), you should use one of the hooks listed above, and use its third parameter.
 * Inside the hook handler, there are two ways to add a variable:
 * The "direct" way is calling . This is ideal only when the value is easy and quick to compute: the value is computed even if no active filter will use it.
 * The "lazy" way is calling . Here, 'method_name' is a (unique) identifier that will be used to compute the variable (it's recommended to prefix it with the name of your extension). To register the method, you should add a handler for the hook; therein, you should check if the $method passed matches your 'method_name', and if so, compute the variable. Lastly, $params is an array of parameters that you'll need to compute the variable; these are passed to the computeVariable hook handler. For an example of this, you can check out CentralAuth's.

Adding custom actions
You can add custom action handlers, so that each filter may perform further actions. To do that, you choose a name for the action ('my-action' from now on), and then:


 * Create a class named e.g. MyAction, that should extend \MediaWiki\Extension\AbuseFilter\Consequence, which can also implement HookAborterConsequence or ConsequencesDisablerConsequence
 * Add a subscriber to the AbuseFilterCustomActions hook; the subscriber should provide a callback as documented in the hook documentation, that returns an instance of the class created above, for instance:

Then you should add the following i18n messages; you can replace 'my_action' with e.g. 'block' to see what the messages are for:



Adding rule groups
You can also add extra rule groups, which can be used to group existing abuse filters. Note that, at the moment, each filter can only be in a single group (T116642). Currently, the only known consumer of this feature is. To do that, you should:


 * Append the name of the group to
 * Add some code to run the filters with your group. Note that AbuseFilter won't do that on its own. To do that, you should construct an  object, passing in the name of your group.