Release status: stable
|Implementation||User activity, Special page, API|
|Description||Allows specific behavior-based restrictions to be placed on wiki activity|
|License||GNU General Public License 2.0 or later|
Translate the AbuseFilter extension if it is available at translatewiki.net
|Check usage and version matrix.|
|Open tasks · Report a bug|
The AbuseFilter extension allows privileged users to set specific actions to be taken when actions by users, such as edits, match certain criteria. (e.g. A filter could be created so that when a user removes more than 2000 characters, they are blocked.)
There are no required dependencies for this extension, but it is reccomended you install Extension:AntiSpoof to use string normalization features.
- Download and place the file(s) in a directory called
- Add the following code at the bottom of your LocalSettings.php:
- Run the update script which will automatically create the necessary database tables that this extension needs.
- Done - Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
Once you installed the extension, you'll have to set up the user rights in
|abusefilter-modify||Modify abuse filters|
|abusefilter-view||View abuse filters|
|abusefilter-log||View the abuse log|
|abusefilter-log-detail||View detailed abuse log entries|
|abusefilter-private||View private data in the abuse log|
|abusefilter-modify-restricted||Modify abuse filters with restricted actions|
|abusefilter-modify-global||Create or modify global abuse filters|
|abusefilter-revert||Revert all changes by a given abuse filter|
|abusefilter-view-private||View abuse filters marked as private|
|abusefilter-log-private||View log entries of abuse filters marked as private|
|abusefilter-hide-log||Hide entries in the abuse log|
|abusefilter-hidden-log||View hidden abuse log entries|
For example, the following sample configuration would allow sysops to do everything they want with AbuseFilter, and everyone to view the log and see public filter settings:
$wgGroupPermissions['sysop']['abusefilter-modify'] = true; $wgGroupPermissions['*']['abusefilter-log-detail'] = true; $wgGroupPermissions['*']['abusefilter-view'] = true; $wgGroupPermissions['*']['abusefilter-log'] = true; $wgGroupPermissions['sysop']['abusefilter-private'] = true; $wgGroupPermissions['sysop']['abusefilter-modify-restricted'] = true; $wgGroupPermissions['sysop']['abusefilter-revert'] = true;
Note: Filters marked as private can only be viewed by users with either the abusefilter-modify or abusefilter-view-private permission.
Creating and managing filters
Once the extension has been installed, filters can be created/tested/changed/deleted and the logs can be accessed from the Abuse filter management page Special:AbuseFilter.
- Rules format - The basics of how to write a filter
- 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.
|Variable name||Default value||Description|
||The possible actions that can be taken by abuse filters.
Additional possible actions:
|$wgAbuseFilterConditionLimit||1000||The maximum number of 'conditions' that can be used each time the filters are run against a change. (More complex filters require more 'conditions').|
|$wgAbuseFilterValidGroups||'default'||The list of "groups" filters can be divided into. By default there is only one group.|
||Disable a filter if it matched more than 2 edits, constituting more than 5 % of the actions which were checked against the filter's group in the "observed" period (at most one day), unless the filter has been changed in the last 86400 seconds (one day)|
||Name of AbuseFilter's parser class.|
||Users must have the "abusefilter-modify-restricted" user right as well as "abusefilter-modify" in order to create or modify filters which carry out these actions.|
||Allows to configure the extension to send hit notifications to Special:RecentChanges or UDP. Available options: rc, udp, rcandudp|
||Enable notifications for private filters.|
||Name of a database where global abuse filters will be stored in (only supported in the latest, development version).|
||Set this variable to true for the wiki where global AbuseFilters are stored in (only supported in the latest, development version).|
||Disallow Centralised filters from taking actions that locally block, remove from groups, or revoke permissions.|
||Duration of blocks made by AbuseFilter|
||Duration of blocks made by AbuseFilter on users who are not logged in. The value of $wgAbuseFilterBlockDuration will be used if this is not set.|
||Callback functions for custom actions.|
||Valid "filter groups" – used for applying edit filters to certain types of actions|
||Default warning messages, per filter group|
||Age used as cutoff when purging old IP log data. Defaults to 3 months. Used by maintenance script purgeOldLogIPData.php.|
Whether to record data about the performance of filters – the average number of conditions used and the time consumed by every filter.
(This was always enabled in MediaWiki up to 1.25, then entirely removed from 1.26 for performance reasons, then restored in 1.27.)
AbuseFilter adds two API list modules, one for details of abuse filters ("abusefilters") and one for the abuse log, since it is separate from other MediaWiki logs ("abuselog"). It is not possible to create or modify abuse filters using the API.
list = abusefilters
List information about filters
abfstartid: The filter id to start enumerating from
abfendid: The filter id to stop enumerating at
abfdir: The direction in which to enumerate (older, newer)
abfshow: Show only filters which meet these criteria (enabled|!enabled|deleted|!deleted|private|!private)
abflimit: The maximum number of filters to list
abfprop: Which properties to get (id|description|pattern|actions|hits|comments|lasteditor|lastedittime|status|private)
When filters are private, some of the properties specified with
abfprop will be missing unless you have the appropriate user rights.
List non-private abuse filters
<api> <query> <abusefilters> <filter id="1" hits="867" /> <filter id="3" hits="66110" /> <filter id="5" hits="464" /> <filter id="6" hits="19" /> <filter id="8" hits="7" /> <filter id="9" hits="24869" /> <filter id="11" hits="10033" /> <filter id="14" hits="63" /> <filter id="15" hits="15" /> <filter id="16" hits="44" /> </abusefilters> </query> <query-continue> <abusefilters abfstartid="18" /> </query-continue> </api>
list = abuselog
List instances where actions triggered an abuse filter.
aflstart: The timestamp to start enumerating from
aflend: The timestamp to stop enumerating at
afldir: The direction in which to enumerate (older, newer)
afluser: Show only entries where the action was attempted by a given user or IP address.
afltitle: Show only entries where the action involved a given page.
aflfilter: Show only entries that triggered a given filter ID
afllimit: The maximum number of entries to list
aflprop: Which properties to get (ids|user|title|action|result|timestamp|details)
List instances where the abuse filter was triggered in response to actions from the user "SineBot"
<api> <query> <abuselog> <item id="900937" filter_id="211" user="SineBot" result="" /> <item id="888404" filter_id="211" user="SineBot" result="" /> <item id="862751" filter_id="211" user="SineBot" result="" /> <item id="855649" filter_id="211" user="SineBot" result="" /> <item id="842429" filter_id="211" user="SineBot" result="" /> <item id="840958" filter_id="1" user="SineBot" result="" /> <item id="824151" filter_id="211" user="SineBot" result="" /> <item id="804892" filter_id="211" user="SineBot" result="" /> <item id="205254" filter_id="58" user="SineBot" result="disallow" /> <item id="205252" filter_id="58" user="SineBot" result="disallow" /> </abuselog> </query> <query-continue> <abuselog aflstart="2009-04-19T02:07:55Z" /> </query-continue> </api>
- Some users might experience that creating new filters or modifying old filters fail and the user just gets redirected to the original page. If the Wiki is using SSL certificates, this error could possibly be because of the
value, which might be using "http://" instead of "https://". An indication of this error will be, the browser giving https warning for Special:AbuseFilter pages. (Topic:T23dyyih0ofjada5)
- Several WMF wikis where it's enabled (and with which configuration)
|This extension is being used on one or more Wikimedia projects. This probably means that the extension is stable and works well enough to be used by such high-traffic websites. Look for this extension's name in Wikimedia's CommonSettings.php and InitialiseSettings.php configuration files to see where it's installed. A full list of the extensions installed on a particular wiki can be seen on the wiki's Special:Version page.|