Extension:AbuseFilter/Actions

Overview

AbuseFilter can take several actions, even more than one at a time. "Logging" and "tagging" are the softer ones, and won't prevent the edit from being saved. "Throttling" and "warning" are special actions, which don't do much on their own: the former only silently increases an internal counter, while the latter warns the user about what they are going to do, letting them amend the edit according to the warning text (or avoid saving the edit at all). "Disallow" is instead a stronger action, and completely prevents the edit from being saved. The other actions, i.e. "blockautopromote", "block", "degroup" and "rangeblock", are even stronger and each of them prevents the edit from completing and applies a specific action on the user themselves.

Some of these actions (specifically, block, degroup and blockautopromote) may be reverted by users with the abusefilter-revert right. It allows users to access the /revert subpage, where they can specify a time period and get a list of revertable actions performed by a specified filter. By confirming the revert, all of these actions will be undone. The form for reverting actions taken by a filter can be accessed with a link found in every filter page, right below the one for accessing the history.

List of actions

The following actions are available in the AbuseFilter extension:

Logging

All filter matches are logged in the abuse log. This cannot be turned off.

Warning

The user is warned that their edit may not be appreciated, and is given the opportunity to submit it again. You may specify a specific system message containing the warning to display.

Throttling

Throttling only works if your MediaWiki instance is using object caching. See task T52894.

The filter will only match if a rate limit is tripped. You can specify the number of actions to allow (a positive integer), the period of time in which these actions must occur (a positive integer), and how those actions are grouped (at least one criterion from the list below, lowercase).

The groupings are which sets of people should have aggregate (shared) throttles. That is, if you type user, then the same user must match the filter a certain number of times in a certain period of time. You may also combine groups with commas to specify that throttle matches sharing all criteria will be aggregated. For example, using ip,page, X filter matches in Y seconds from the same IP address to the same page will be required to trip the remainder of the actions.

Here is the full list of available groups:

ip – IP address.
user – User account.
range – /16 range for IPv4, /64 range for IPv6.
creationdate – User account creation date, server time.
editcount – Edit count — hack so that you can detect distinct users.
site – The whole site.
page – Page

When applying a throttle to an edit filter, it is important that you do so using both the ip and user variables wherever possible (as opposed to using either or).

Throttling by user alone throttles by user id, not by username. All logged out editors share one user id, which is 0. This may cause false positives and issues if many anonymous users unrelated to one another match the filter conditions when saving edits.

Throttling by ip alone throttles logged in editors by their underlying IP address. Do not use only the ip variable when applying a throttle, unless the filter specifically targets logged out or anonymous users only.

Disallowing

Actions matching the filter will be prevented, and a descriptive error message will be shown.

Revoking auto-promoted groups

Actions matching the filter will cause the user in question to be barred from receiving any extra groups from $wgAutopromote for 5 days. This can be restored at the debug tools page.

Warning:

This action also affects administrators, even its creator. If an administrator has their right revoked, they will not be able to access the AbuseFilter page to disable the filter or to restore their status for a while. Checking user's group first is the good way.

Blocking

Users matching the filter will be blocked for the time specified, with a descriptive block summary indicating the rule that was triggered.

Removing from privileged groups

Users matching the filter will be removed from all privileged groups (sysop, bureaucrat, etc). A descriptive summary will be used, detailing the rule that was triggered.

Range-blocking

Somewhat of a "nuclear option", the entire /16 (IPv4) or /19 (IPv6) range from which the rule was triggered will be blocked for the time specified.

Tagging

The edit or change can be 'tagged' with a particular tag, which will be shown on Recent Changes, contributions, logs, new pages, history, and everywhere else. These tags are styleable, so you can have items with a certain tag appear in a different colour or similar.

Show a CAPTCHA

Warning:

This only works when the action is an edit. Other actions may work, but there is no guarantee.

This only works when the ConfirmEdit extension is installed.

When ConfirmEdit is installed, this will cause a CAPTCHA to be displayed. If the CAPTCHA is passed, then the next edit attempt will apply other actions if the filter still matches the edit.