Jump to content

Extension talk:AbuseFilter/Archive 1

From mediawiki.org

Filters have no effect

I'm having crazy problems with the AbuseFilter extension, and I can't get any filters to do anything at all. No matter what kind of actions I try to filter out, they get through without the Abusefilter doing anything to stop them, it doesn't even log the events in the abuse log. Even running it in test mode and comparing all the old edits, nothing matches the filter. For example, the "shouting" filter which is intended to catch anyone typing in BLOCK CAPITAL LETTERS, completely ignores anyone who has been doing it.

It's blind.

The filters I've been trying are the ones wikipedia itself uses, so they should definitely work. For some reason it just doesn't seem to be paying attention to any of the edits though.

I have two other extensions installed, AntiSpoof and "bad behaviour"... Apparently AntiSpoof is required before you can install AbuseFilter, so I doubt there could be any conflict there. Bad behaviour is working effectively, so effectively that it wouldn't allow me to install AbuseFilter to begin with because it seemed to think the installer was a bot or something? So I had to temporarily disable it in order to get AbuseFilter installed. Bad behaviour is still currently disabled so I don't think there could be any conflict there either.

I'm on mediawiki 1.16, the latest one. My extensions are all also the versions which go with 1.16. The server is Apache/Linux. PHP 5.2.42 and MySQL 5.0.85.

Has anyone heard of this happening before, or got even the slightest clue what the problem could be? Even the faintest idea or the wildest guess would be helpful, anything to give me something to look into. I've got nothing. Asndb 02:26, 13 September 2010 (UTC)Reply


Possible postgres problem

I try to install AbuseFilter on a fresh wikifamily. But when I try to access the Special:AbuseFilter page I get this error:

 Warning: pg_query() [function.pg-query]: Query failed: FEHLER: Spalte »abuse_filter.af_enabled« muss in der GROUP-BY-Klausel erscheinen oder in einer Aggregatfunktion verwendet werden in /mediawiki-data/  mediawiki-1.15.3/includes/db/DatabasePostgres.php on line 5

The required tables where created with this command (this errors are here because I executed it twice, I think):

 php ../mediawiki-extensions/AbuseFilter/install.php --conf LocalSettings.php
 Warning: pg_query(): Query failed: FEHLER:  Relation »abuse_filter_af_id_seq« existiert bereits in /var/www/mediawiki-data/mediawiki-1.15.3/includes/db/DatabasePostgres.php on line 580
 A database error has occurred
 Query: CREATE SEQUENCE abuse_filter_af_id_seq
 Function: Database::sourceStream
 Error: 1 FEHLER:  Relation »abuse_filter_af_id_seq« existiert bereits

Is there something missing? Do I have forgot something? nuss0r

Syntax error

I have installed this extension on a localhost Wiki but for some reason it rejects any filter I add and gives the error message:

There is a syntax error in the filter you specified. The output from the parser was:

And it gives no output from the parser. I know the syntax is correct because even simple things like "testing in SUMMARY" are rejected. Is this a bug, or have I done something wrong? 125.238.97.240 11:11, 14 September 2008 (UTC)Reply

Throttling

What does "# editcount — Edit count — hack so that you can detect distinct users." mean?  — Mike.lifeguard | @meta 00:04, 20 February 2009 (UTC)Reply

Some problems

There are a few problems with this extension

Actions only visible to the editor should not have public logging
Logging is not something where one level fits all, especially when it comes to public verbal attack on living persons. As a first approach access to the log items can be given on an action level, but probably this will also lead to a lot of problems. At least there should be possible to turn of logging for trivial actions which never give any public effect. For example, if a warning is given and the editor then avoid storing the edit, then no logging should happen. If he continue the upload of the edit, then the warning can be logged. Still note that the logging itself can release information about the topic described in the edit.
Public rules could itself be a violation of privacy given specific articles
Imagine someone gets some information that s/he assume could lead to legal action if published. This information is then used to write one or more rules for prohibiting said information from reaching a wiki. If this information is clear text then it can be easily inverted into the information that should be excluded. This happens most typically when the article in question is a biography and the rule is about some kind of rumor or fact, especially when such rumors or facts are illegal to publish. One solution is to make special digests instead of clear text in the rules.
Regex patterns are overly simplistic for analyzing real life vandalism
As long as the vandalism can be described by simple patterns matching singular markers thing works out pretty well. If the vandalism isn't simple words but phrases, then it becomes a lot more troublesome to detect such vandalism. Some previous work indicates that whole phrases should be analyzed anyhow, and that an approach with simple words are to simplistic, and will lead to a much to high number of false positives.

Probably there are other problems, but those are very close to show stoppers. Jeblad 20:26, 22 February 2009 (UTC)Reply

You have obviously not examined the extension in detail. The last two are obvious non-issues, the second because rules can be hidden from the general public, and the third because the whole point of the extension is that it goes beyond regexes to more complicated boolean logic based on far more context than just a regex match.

The first is something that needs to be debated – it may be worthwhile offering this as a configuration option. Andrew Garrett 03:32, 23 February 2009 (UTC)Reply

Limiting public disclosure to an smaller unidentified group is not good enough, ie you can not guarantee that it will not be diclosed by someone because you can't identify the persons having the opportunity to inspect the actual information (in Norway that is «behandlingsansvarlig» for such information[1]). It seems to me that the only viable solution is to either create a limited group of identified persons, as for the OTRS-system on Wikimedia, or to make encrypted rules that is identifiable but which can not be read in clear text. Perhaps it is acceptable in some countries, but in those countries where you must identify who has access it can create some real problems. The same goes for logging, as logging and rules are symmetric in this respect.
A similar problem is to protect the rules itself from probing. Imagine a rule guarding an article from inclusion of a rumor about someone being raped, and then a reader wants to verify the rumor so he inserts some text with the word "rape" in it. If he is blocked, or even just given a warning, then he know that the rumor is known and the information is leaked by the action itself. The system must have some capability to obfuscate the actual action and the reason behind. One such method is to trigger on not only clear text patterns but on digests of word(s) where the digest algorithm has a low entrophy. This will make it difficult to reverse engineer the words, and also give an increased number of false positives. If such a rule is only used for blocking upload to a single article it would not pose a problem as long as it does not involve blocking of the editor himself.
I know that there is a system for boolean logic, but this still does not solve the complexity of parsing natural language. Without such capabilities the error rate will be far to high. Compare the two statements "He is a monkey" vs "It is a monkey". Jeblad 11:41, 23 February 2009 (UTC)Reply
Furthermore, "He is a monkey" is just fine in, say, "Curious George" on Wikipedia or other pages about fictional characters. --Damian Yerrick 13:44, 2 July 2011 (UTC)Reply

Proximity operators

If the solution is to be used for text analysis, then proximity operators should be added. Such operators typically act within some logical text unit such as a paragraph, a sentence or similar, or within a number of words. Jeblad 20:56, 23 February 2009 (UTC)Reply

Beta status

The trials on en:wp: prove that the abuse filter works, could the status be changed to beta?--Ipatrol 00:21, 19 March 2009 (UTC)Reply

Documentation?

Greetings. I am a sysop at en.wikiquote, where there is some interest in employing this extension. Is there self-contained documentation available or forthcoming, or is this tool intended to be used only by persons who are conversant with its run-time environment? ~ Ningauble 16:52, 21 March 2009 (UTC)(talk@wq)Reply

Documentation shortcomings

It says

The abuse filter passes various variables by name into the parser.

Those need to be documented. AxelBoldt 17:36, 23 March 2009 (UTC)Reply

Yes, please! ~ Ningauble 15:42, 24 March 2009 (UTC)(talk@wq)Reply

Installation is hard

I cant execute command line scripts due to shared hosting so I cant run update.php or install.php. Other extensions are very easy to install: only the 'include' is required in LocalSettings.php. This one involves a little more. --Kenny5 02:29, 30 March 2009 (UTC)Reply

If you can't run scripts how did you get MediaWiki installed in the first place? 86.149.15.167 15:30, 10 April 2009 (UTC)Reply
Um, you can. All you need to do is create a database, user and let the installer run its own script after you FTP the files. You dont need command line access. --Kenny5 16:41, 10 April 2009 (UTC)Reply


What to do in case of "unexpected T_STRING" error

Individuals running maintenance/update.php or ~/YOURDOMAINNAME.com/extensions/AbuseFilter/install.php from the command line may encounter the following error:

syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in ~/mainteance/commandLine.inc on line 13

This error occurs when update.php or install.php is run from php4.

Individuals who have their site hosted by providers whom provide both php4 and php5 should take the following steps:

  1. from the command line, enter the command 'whereis php5'
  2. once you have discerned the location of the php5 path, list the director of the php5/bin directory
  3. once you've determined the name of the php executable (either php or php5), then type in the entire path to execute install.php

Below is an example:

$ whereis php5
$ ls -la ls /usr/local/php5/bin
$ /usr/local/php5/bin/php install.php

DeanPeters 16:15, 15 August 2010 (UTC)Reply

Tags

How do I create stylable tags, so I can have items with a certain tag appear in a different colour or similar? The tags appear in Special:Tags, but how do I make them appear in a different color in recent changes? --Petter 09:07, 5 April 2009 (UTC)

Documentation

Note to werdna: Can you please expand and update the documentation . 04:51, 21 April 2009 (UTC)

Adapt I/O for augmenting templates?

This seems to be a more reasonable language for transclusion templates than the traditional parser expansion.WMFBlog:2009/06/on-templates-and-programming-languages/.

For that to work, there is a need to take input from template parameter arguments and emit generated wikitext. I believe that this is related to r50997 and/or r51497 but I'm not entirely sure how. Best of luck! 99.22.93.63 18:18, 1 August 2009 (UTC)Reply

How to import Wikipedia abuse filter?

Want to use it in my local wiki.

--Nettroll 12:20, 3 September 2009 (UTC)Reply

When you have installed the extension, go to w:en:Special:AbuseFilter, choose a filter (say w:en: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. --Nemo bis 12:26, 3 September 2009 (UTC)Reply
These pages' content is no longer available to the public. Is there some other source of rules? Daenks (talk) 15:07, 11 June 2014 (UTC)Reply

MediaWiki version

I would like to ask which MediaWiki version is needed for this extension? Thanks. 77.20.39.5 18:36, 13 December 2009 (UTC)Reply

It appears that it works for 1.13+, just grab the correct version of the extension for your version of mediawiki (see the dropdown here) --Skizzerz 20:04, 13 December 2009 (UTC)Reply

Images & Special characters on same page producing fatal error in AbuseFilter

I have encountered the following fatal error when I try to include both images and special characters on the same page while having Abuse Filter switched on:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 24 bytes) in $IP/extensions/AbuseFilter/AbuseFilter.i18n.php on line 12320

In the meantime, I am disabling Abuse Filter but would like to re-enable it should this be a simple matter to resolve. Does anyone have any ideas that might help me out? (I replaced the full address of the error above with $IP for security reasons) --Ds093 23:10, 10 February 2010 (UTC)Reply

Check your memory limit in LocalSettings. You may want to raise it.
# If PHP's memory limit is very low, some operations may fail.
ini_set( 'memory_limit', '64M' );
--Subfader+
Thank you Subfader. I actually happened to notice that for myself just a few hours ago. I meant to come back here and mention that I had myself then, but I had to go out and just got back.--Ds093 23:54, 13 February 2010 (UTC)Reply

Conflicts with TemplateFormEditor

This extension does not work when the TemplateFormEditor is installed becouse for some reason it does not trigger the abuse filter hooks. Does anyone have had the same issue ???

--abel406 23:04:19, 02 June 2010 (UTC)Reply

AbuseFilter actions

I'm evaluating Extension:AbuseFilter for use on our internal wiki, and trying to learn how it all works. When configuring a filter, under Actions taken when matched, I see a Flag the edit in the abuse log checkbox, but it's disabled (greyed out) so I can't click on it to clear the checkbox, and I can't figure out how to enable it. Is there any way to enable this option so I can clear the checkbox and prevent posting a triggered event to the Abuse log?

--Obliquemotion 18:18, 11 June 2010 (UTC)Reply

It's probably intentional this way, see en:Wikipedia talk:Edit filter/Archive 5#Filter actions. —AlexSm 16:07, 2 August 2010 (UTC)Reply

Only one edit per page

I'd like to know if it is possible to use some coding for the filter to non-autopatrolled users to one edit per page per, say, five minutes. I can't find any functions to do so, though. Could someone please help me out with this? (To clarify: I want them to be able to edit as much as they please but to be limited to one edit per specific page. They can make like thirty edits as long as they are made to different pages.)173.168.217.112 01:22, 1 August 2010 (UTC)Reply

This is not a place to ask this, and such a filter looks very strange to me, but the answer is: use &! user_name in article_recent_contributors. —AlexSm 16:07, 2 August 2010 (UTC)Reply
How is it not a place to ask? I'm discussing the usage of the extension. Anyways, I appreciate it.173.168.217.112 17:46, 2 August 2010 (UTC)Reply
You can't really expect a reply here (my response was more of an exception). You might have better luck asking questions at enwiki AF page. —AlexSm 14:26, 3 August 2010 (UTC)Reply
I'd be interested in creating a similar filter, but my attempts to use the throttling options to limit by user,page haven't worked as expected (or at all). Can anyone show a working example, or give any tips? Thanks! Adamcox82 17:53, 2 August 2010 (UTC)Reply
Throttling is tricky indeed. Try to look at existing filters, e.g. get a list of enwiki public filters, look for "throttle" and then look at the code: en:Special:AbuseFilter/80, etc. —AlexSm 14:26, 3 August 2010 (UTC)Reply
Throttling fails completely when attempting to use it. Adam and I have attempted the same thing, and the filter has matched the edits, but the throttle refuses to trip. I'd like to know why.Neo of ZW 18:16, 6 August 2010 (UTC)Reply

Examples of Filters

After successfully installing AbuseFilter Extension, I wasn't able to really use the examples in the extenion's WIKI page.

I also noted some others asking for documentation. So I'm going to start a list here of filters to encourage others to collaborate on filters they've implemented.

Content

  • Newly entered, formatted content:
    "illegal word or phrase" in new_wikitext
  • New title or newly entered content, filtered & unfiltered,
    "testfilter" in new_wikitext | "testfilter" in new_text | "testfilter" in lcase(article_text)
  • User adds more than 3 external links in a single edit
    count("http://", added_links) > 3

-- DeanPeters 16:59, 15 August 2010 (UTC)Reply

Thanks - just what I needed. I was looking for a way to block all links from new users - the spambots are overrunning the CAPTCHA defences...!
The last one should include https:// links as well (just in case - not sure if they're actually common in spam). I tried
count("https?://", added_links) > 0
- but it didn't work. (The s? in regex means an optional s, so it should match http and https links, but somehow regex isn't working here...?)
So I tried this Boolean match, to find both http and https, and it worked:
count("http://", added_links) > 0 | count("https://", added_links) > 0
as a way to --Chriswaterguy 12:02, 7 December 2011 (UTC)Reply

Problem with Class 'Html' not found Faltal Error

I have just svn AbuseFilter in my wiki but I get the following Fatal Error at Special:AbuseFilter

Fatal error: Class 'Html' not found in [...]/w/extensions/AbuseFilter/Views/AbuseFilterViewList.php on line 91

Chlewey 19:31, 17 November 2010 (UTC)Reply

I changed Html::hidden in line 91 for Xml::hidden. Now I get the following code:
<abusefilter-topnav> (<abusefilter-topnav-home> | <abusefilter-filter-log> | <abusefilter-topnav-test> | <abusefilter-topnav-examine> | <abusefilter-topnav-log> | <abusefilter-topnav-tools> | <abusefilter-topnav-import>)

 <abusefilter-intro>

 <abusefilter-new>
 <abusefilter-list>
 <abusefilter-list-options>
 <abusefilter-list-options-deleted>	 <abusefilter-list-options-deleted-show> <abusefilter-list-options-deleted-hide> <abusefilter-list-options-deleted-only>
 <abusefilter-list-options-disabled>	 <abusefilter-list-options-hidedisabled>
 <abusefilter-list-limit>	

Chlewey 20:46, 17 November 2010 (UTC)Reply
Trying to import a filter, I got the following error:
Fatal error: Call to undefined function wfobjecttoarray() in [...]/w/extensions/AbuseFilter/Views/AbuseFilterViewEdit.php on line 758
Chlewey 20:49, 17 November 2010 (UTC)Reply

Global Abuse Filter

This is in the config's table on the extension page > $wgAbuseFilterIsCentral > "Set this variable to true for the wiki where global AbuseFilters are stored in (if you're using global filters)."

I can't find anything on "GlobalAbuseFilter"

Mlpearc powwow 01:58, 19 September 2011 (UTC)Reply

Preliminary code for a global abusefilter has been developed somewhere... it hasn't been worked on due to some initial opposition to it (from what I've heard), though I'm trying to find out more. Ajraddatz 20:12, 5 February 2012 (UTC)Reply

Apply filters

Hi,

this extensions works fine for modifications on my wiki. But I'd like to apply the rules to the changes that have been made before I installed the AbuseFilter. There is a way to test the filters, but I didn't find a "apply changes" button or so.

Best regards --Schubi87 10:48, 7 November 2011 (UTC)Reply

Xml:hidden

This extension uses the Xml::hidden method, wich is deprecated. If using 1.18, this extension won't work. Solution is simple: replace all Xml::hidden occurrences for Html::hidden.

PS: A quick way to do this is to execute this command in a shell, in the AbuseFilter directory:

find ./ -type f -exec sed -i 's/"Xml::hidden"/"Html::hidden"/' {} \;

(it should work for any extension with this problem, tho) --Krusher 12:26, 29 November 2011 (UTC)Reply

Logic tips for non-coders

Some tips for non-coders on how the Boolean works would be good. E.g.:

  • Logic carries over between line breaks.
  • The & (AND) operator is applied before | (OR).

Therefore if you want to flag and edit that matches a user condition either A or B, and also matches edit condition C or D, then you need brackets to group the logical statements:

(A | B)
&(C | D)

If you leave these out, like this:

A | B
&C | D

...this can lead to false positives.

E.g. to stop brand new users posting a url, you might use:

(user_age < 2*3600 | user_editcount < 1)
&count("http://", added_links) > 0 | count("https://", added_links) > 0

The brackets are important!

Maybe someone wants to check what I've written here, correct as needed, and put it on Extension:AbuseFilter/Rules format? --Chriswaterguy 04:10, 23 December 2011 (UTC)Reply

Verbose log?

I'd love to have a more verbose form of the log. I don't want to click through to check 100 different blocked edits, but if the first 100 or 500 words of the attempted diff could be displayed in the log, I could more easily scan for false positives.

Thanks for the extension by the way - it's been a fantastic help on Appropedia. --Chriswaterguy 04:21, 23 December 2011 (UTC)Reply

SQLite database error

When I try to install MediaWiki with the AbuseFilter extension, a syntax error occurs when parsing abusefilter.tables.sql (a MySQL dump file) with SQLite and installation of AbuseFilter was skipped. I copied AntiSpoof into the extensions directory because AbuseFilter "requires AntiSpoof" but did not install MediaWiki with AntiSpoof because trying to install AntiSpoof crashes the installer because of an unhandled SQLite syntax error when parsing the MySQL dump file for the AntiSpoof tables. An SQL dump of my fresh wiki is shown below so the developer can experiment with it and attempt to write a working SQLite database dump in reply.

(SQLite dump excised to /SQLite dump so it doesn't bog down this page with horrible load times Dr ishmael (talk) 16:50, 16 March 2012 (UTC))Reply

Additional information: MediaWiki 1.18.1, PHP 5.3.10

Disallow + block

I'm trying to set up a spambot prevention that disallows obvious spam edits and blocks the user responsible, giving a warning first. However, the filter only seems to apply the disallow part and only randomly choose to block the user as well. When I removed the disallow consequence, the next test edit was both disallowed and the account blocked, the next test edit passed after the warning without consequences. Am I doing something wrong, or is the block consequence buggy? --Sovereign92 (talk) 21:22, 27 February 2012 (UTC)Reply

I'm no expert, but I haven't experienced this. Are you able to share your filter code? --Chriswaterguy (talk) 06:02, 9 March 2012 (UTC)Reply

article_namespace != 1|2|3 & !("confirmed" in user_groups) &
(contains_any(new_text,
"test123",
"test321",
))

warn, disallow, block, tag

--Sovereign92 (talk) 17:59, 9 March 2012 (UTC)Reply

Try enclosing the 1|2|3 in brackets. I get odd behavior in testing logic of the form article_namespace != 1|2|3 & - but it stops when I change it to the form article_namespace != (1|2|3) &
My next thought would have been to add quotation marks, i.e. "(1|2|3)" - but that's probably unneeded. Hope that helps. --Chriswaterguy (talk) 20:23, 9 March 2012 (UTC)Reply
I encountered this same bug. See thread at bottom. Dcoetzee (talk) 02:15, 11 April 2012 (UTC)Reply

user_age in "Examine individual changes"

I found a confusing thing. A spammer registered, then 8 minutes later created a page. So user_age should be approximately 8*60. But when I examine the edit, it gives the user_age as the current age, rather than the age when they made that individual change.

I spent quite a lot of time trying to debug a filter before I realized what was going wrong. Hope this helps someone else. --Chriswaterguy (talk) 19:19, 3 March 2012 (UTC)Reply

A few more options...

  • Bot-related
    • Prevent bots from performing this action (to exempt legitimate bots, add '!"bot" in user_groups') - If the spammer/vandal uses index.php to perform the action, ConfirmEdit is installed, and the ConfirmEdit options in LocalSettings.php are set correctly, tell ConfirmEdit to trigger a CAPTCHA if installed. If the spammer/vandal is using some other PHP program on the server (eg. api.php) to perform the action with MediaWiki, disallow the action which triggers this filter.
    • Warnings and disallow information for bots - gives the information about the triggered filter IDs and unformatted warning messages or disallow information (for example, <abusefilter-warning id="58">Be aware that, if you post your email address publicly, this can increase spam sent to your email address. If you want people to email you, tell them to use Special:EmailUser</abusefilter-warning> if actions taken are "Warn", <abusefilter-error id="113">You have tried to replace an article with nonsense and this has been disallowed.</abusefilter-error> if actions taken are "Warn, Disallow", or <abusefilter-error id="276" /> if actions taken are "Disallow".
  • Autoreverted revision (edit only) - perform the edit but see the revision automatically reverted by "Abuse filter" unless an exempted user group in the filter performs the edit

Comments in code

Is there a way of adding comments in the code? I read that (?#COMMENT) works in Python regex (and this is confirmed in this page, which was linked from a guide to PCRE syntax) but I can't make this work in AbuseFilter.

I tried this simple test filter:

user_age < 3600 (?#COMMENT)

and it gives the error "Syntax error detected: Unexpected "T_BRACE" at character 15."

Putting it on a separate line or using & or + didn't work either. Any clues? --Chriswaterguy (talk) 12:00, 9 March 2012 (UTC)Reply

The ability to comment the filter code would be a wonderful addition to this extension. I have trouble remembering what a complex filter is actually doing when I look at it even a couple months later. I know there's a "Notes" box, but that is a poor substitute for in-line comments. Dr ishmael (talk) 16:52, 16 March 2012 (UTC)Reply

How can I use createaccount?

I'd love a way to reduce the creation of accounts by spam bots - is there something I can do when the action is createaccount?

I'd love to have a custom field as a trap for spam bots - either a super-simple CAPTCHA (e.g. enter the word cat or Leave this blank - the latter one hidden by CSS). Then AbuseFilter could check the inputs for those boxes. I assume that would take some hacking of AbuseFilter, but not sure how much.

Is there anything we can do with createaccount without hacking? Thanks --Chriswaterguy (talk) 17:52, 3 April 2012 (UTC)Reply

For that there's Extension:QuestyCaptcha. A set of site-specific questions and answers has proven itself very effective at preventing untargeted spam on a wiki that I administer. --Damian Yerrick (talk) 18:38, 9 May 2012 (UTC)Reply

Database error

I keep getting this message when I try to use this extension: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

   (SQL query hidden)

from within function "IndexPager::reallyDoQuery (AbuseLogPager)". Database returned error "1146: Table 'my_wiki.abuse_filter_log' doesn't exist (localhost)". What should I do?--Breawycker (talk) 01:39, 6 April 2012 (UTC)Reply

You have forgotten to run update.php.--Jasper Deng (talk) 01:40, 6 April 2012 (UTC)Reply

Username whitelist on registration

Due to this spam bot problem, I'm planning to make a whitelist of allowed usernames, however, my code doesn't work as supposed and blocks registering altogether.

action = 'createaccount' & accountname != ("Test1 | Test2")

I have tried with and without brackets. --Sovereign92 (talk) 14:43, 6 April 2012 (UTC)Reply

Try using an rlike expression instead of comparing the entire username to the string "Test1 | Test2". --Damian Yerrick (talk) 14:32, 18 October 2012 (UTC)Reply

Not blocking

I have some rules for which I checked "Prevent the user from performing the action in question" and "Block the user and/or IP address from editing" but it seems to only work sporadically. At first it blocked some IPs, and it just blocked one again, but most of the time it only prevents the edit but does not block. See: [2], [3]. I'm not sure what's going on, is this a bug or am I missing something? Thanks! Dcoetzee (talk) 02:13, 11 April 2012 (UTC)Reply

I think maybe I figured this out. My wiki's legit traffic is really low, so over 50% of traffic is blocked by the abuse filter, which is far above the default threshold. I set:
$wgAbuseFilterEmergencyDisableThreshold = 1.0;
$wgAbuseFilterEmergencyDisableCount = 1000000;
I then made small changes to each of my filters to reset the af_throttled. Since then my filters seem to be blocking. I checked with "SELECT af_id, af_throttled FROM abuse_filter" if any filters are throttled and none appear to be any longer. I'll see if it continues to work. Dcoetzee (talk) 15:20, 11 April 2012 (UTC)Reply

I dunno, just wanted to let you know I'm interested in this possible bug. I've never had problems. I'm running MW 1.18.1, should try it. Tim (SVG) 17:02, 11 April 2012 (UTC)Reply

Suggestion: user agent

A lot of spammers can be readily identified by the user agent string they use (which may or may not be a real user agent string). It'd be really useful if AbuseFilter rules were able to examine the user agent of an editor. I don't think this would require changes to MediaWiki, since this info is available globally. Dcoetzee (talk) 19:41, 16 April 2012 (UTC)Reply

Cloning the user agent is not a big hurdle. I've checked user agents of several vandals changing their IP every five minutes. The user agent I got by CheckUser query is Mozilla/4.0, and I doubt they are using this browser. Tim (SVG) 20:08, 16 April 2012 (UTC)Reply

Not working at all

Got a few problems on a wiki running AbuseFilter:

  1. I keep getting the following error on a Bureaucratic and Administrator Account on WikiBound:

You do not have permission to view abuse filters, for the following reason: You are not allowed to execute the action you have requested.

  1. No links to any extension-related pages show up in Special:SpecialPages.
  2. The only rights that show up on Special:ListGroupRights are the default rights of the extention... not any custom groups I enabled.

Thank you in advance for the help. Bud0011 (talk) 18:06, 6 May 2012 (UTC).Reply

Did you remember to set up the $wgGroupPermissions?--Jasper Deng (talk) 19:35, 6 May 2012 (UTC)Reply
That I did. I mean, I did recall to do it, and still nothing happens. Bud0011 (talk) 19:58, 6 May 2012 (UTC)Reply
What were your custom groups?--Jasper Deng (talk) 01:36, 7 May 2012 (UTC)Reply
Not exactly how I have it configure, but as a sampling:
groups
$wgGroupPermissions['*']['abusefilter-log-detail'] = true;
//$wgGroupPermissions['*']['abusefilter-view'] = true;
$wgGroupPermissions['*']['abusefilter-log'] = true;

$wgGroupPermissions['*']['abusefilter-modify'] = false;
//$wgGroupPermissions['*']['abusefilter-private'] = false;
$wgGroupPermissions['*']['abusefilter-revert'] = false;

$wgGroupPermissions['user']['abusefilter-modify'] = false;
$wgGroupPermissions['user']['abusefilter-private'] = false;
$wgGroupPermissions['user']['abusefilter-revert'] = false;

$wgGroupPermissions['autoconfirmed']['abusefilter-modify'] = true;
$wgGroupPermissions['autoconfirmed']['abusefilter-private'] = true;
$wgGroupPermissions['autoconfirmed']['abusefilter-revert'] = true;

$wgGroupPermissions['bot']['abusefilter-modify'] = true;
$wgGroupPermissions['bot']['abusefilter-private'] = true;
$wgGroupPermissions['bot']['abusefilter-revert'] = true;

$wgGroupPermissions['sysop']['abusefilter-modify'] = true;
$wgGroupPermissions['sysop']['abusefilter-private'] = true;
$wgGroupPermissions['sysop']['abusefilter-revert'] = true;

$wgGroupPermissions['Oddball']['abusefilter-modify'] = true;
$wgGroupPermissions['Oddball']['abusefilter-private'] = true;
$wgGroupPermissions['Oddball']['abusefilter-revert'] = true;

$wgGroupPermissions['bureaucrat']['abusefilter-modify'] = true;
$wgGroupPermissions['bureaucrat']['abusefilter-private'] = true;
$wgGroupPermissions['bureaucrat']['abusefilter-revert'] = true;
Bud0011 (talk) 02:06, 7 May 2012 (UTC)Reply
Perhaps place these after you include the AbuseFilter files?--Jasper Deng (talk) 02:11, 7 May 2012 (UTC)Reply
Sorry, but I've tried before and after. Bud0011 (talk) 23:13, 7 May 2012 (UTC).Reply
Can I see all your settings? (besides private settings like DB settings and $wgSecretKey of course) If I can't find anything wrong with your LocalSettings.php I'll have to refer to a developer.--Jasper Deng (talk) 23:22, 7 May 2012 (UTC)Reply
Yeap, here it is. Bud0011 (talk) 00:09, 9 May 2012 (UTC)Reply
Should be working fine...--Jasper Deng (talk) 00:27, 9 May 2012 (UTC)Reply
Ok, some progress (I think) on my end. I moved all of the related premissions to after this line of code in the file:
$wgGroupPermissions = array();

and now stuff like this is showing up

  • &amplt;abuselog&ampgt;

in Special:SpecialPages, and please take a look at [4]. Bud0011 (talk) 01:20, 9 May 2012 (UTC)Reply

Those kinds of things mean that for some reason some interface messages in the MediaWiki: namespace are missing...--Jasper Deng (talk) 01:21, 9 May 2012 (UTC)Reply

Why is blocking indefinate?

I'd like to configure how long an IP should be blocked after triggering my filter. How to?--19:25, 18 July 2012 (UTC)

Documentation missing : user rights

Hi,

Could someone improve the documentation at Extension:AbuseFilter#User_rights?

Especially, the right abusefilter-revert isn't straightforward to understand. --Dereckson (talk) 08:04, 29 September 2012 (UTC)Reply

Done. --Dereckson (talk) 08:13, 29 September 2012 (UTC)Reply

Remove AbuseFilter updates from Special:RecentChanges?

Does anyone know how to hide filter changes from Special:RecentChanges? I would really appreciate your help.

Thanks.

$wgAbuseFilterBlockDuration for IP addresses

Is it possible to set up a different block duration if the account was an IP address? --Romanski (talk) 17:31, 17 November 2012 (UTC)Reply

$wgAbuseFilterCentralDB

It seems like there are several small errors in the documentation, and also parts that is left out. It would be nice i those gets fixed. Especially the line

$wgAbuseFilterCentralDB – null – Name of a database where global abuse filters will be stored in (this is not yet supported).

Unless I'm completly off this value should be false, and if it is set to null the code will fail. his is documented in the code, but the documentation on the subject page fails to follow the code. Jeblad (talk) 18:23, 29 November 2012 (UTC)Reply

Tor_Exit_Node

I'm experiencing some strange behavior with the Tor_Exit_Node variable. It doesn't seem to be applied to edits where it should be, it's not even showing up as a property with a value of 0 when I examine individual changes, let alone a value of 1. Is there something extra that needs to be done to enable this feature? Jarandhel (talk) 12:35, 14 January 2013 (UTC)Reply

Update: I'm not sure what changed, but it appears to be working now. 76.100.19.118 04:17, 16 January 2013 (UTC)Reply

How can I remove logs?

I want to empty the logs because they eats lots of disk spaces. Will empty the abuse_filter_log table and all related rows in the text table do the job? And can I limit the log number to 1000 or so? --Superxain (talk) 12:25, 28 January 2013 (UTC)Reply


some Problems

require_once( "$IP/extensions/AbuseFilter/AbuseFilter.php" );

$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;
  • now -> php update.php runs to the error PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7864320 bytes) in /var/www/vhosts/familienfreund.de/httpdocs/lexikon/extensions/AbuseFilter/AbuseFilter.i18n.php on line 18877
  • now i wrote into the localsettings # If PHP's memory limit is very low, some operations may fail.

ini_set( 'memory_limit', '64M' );

Making sure I didn't miss something

Just making sure I didn't miss something before I file a bug.

MediaWiki 1.19.3 PHP 5.3.20 (apache2handler) MySQL 5.5.27-cll

Installed, AntiSpoof and AbuseFilter. Ran the update script, all tables created. Everything seems fine, Special pages work, moving pages, creating pages. The problem is deleting pages. Had to delete a spammer's new page in Main namespace. Blocked them, then went to delete the page which resulted in this.

Warning: Missing argument 5 for AbuseFilterHooks::onArticleDelete() in /home/docsj/public_html/extensions/AbuseFilter/AbuseFilter.hooks.php on line 271

Notice: Undefined variable: status in /home/docsj/public_html/extensions/AbuseFilter/AbuseFilter.hooks.php on line 282

Fatal error: Call to a member function merge() on a non-object in /home/docsj/public_html/extensions/AbuseFilter/AbuseFilter.hooks.php on line 282

Was really looking forward to using this extension. Seemed to work on my local installation of 1.19.2 just fine. Then I updated it and same Fatal Error. I cannot delete a page unless I disable AbuseFilter. Any help or ideas appreciated. Or do I need to file a bug?

--Thanks Hutchy68 (talk) 04:37, 24 February 2013 (UTC)Reply

Retracing steps, master branch breaks when used with MW 1.19, REL1_19 head (needs to be easier to find) downloaded and works without throwing the Fatal Exception error. Needs to be a better version differentiation on the page for what version of AbuseFilter to download, version works with what version of MW. Saying MW 1.13+ is too vague. Hutchy68 (talk) 16:32, 24 February 2013 (UTC)Reply

The problem is deleting pages.

Version:

CentOS 6.3 2.6.18-028stab101.1

PHP 5.3.20 (cli) Zend Engine v2.3.0, eAccelerator v0.9.6.1

MediaWiki 1.22wmf1 (7bb4399)

Abuse Filter (e87bb7a)


When I delete any page I get the message:

warning: strpos() [function.strpos]: Empty delimiter in /*/*/*/extensions/AbuseFilter.parser.php on line 1894

This string is:

if ( strpos( $s, $needle ) !== false ) {

Emergency options need updating

There are three PHP variables listed for the "emergency" options, but the description talks about four variables. Can this please be updated, preferably with the names of the variables themselves rather then X, Y, Z, and S, so that it's clear what controls what. Thanks! – RobinHood70 talk 19:55, 7 April 2013 (UTC)Reply

Verify extension requirements

I've been able to run this extension successfully on MediaWiki 1.20.2 without installing Extension:AntiSpoof. --Lethosor (talk) 21:22, 23 April 2013 (UTC)Reply

Per what I wrote on Extension_talk:ConfirmEdit:

My wiki has been overrun by spambots. Thankfully because of this extension, these spambots are not able to edit the pages, but they are still able to create an account - about 50 new accounts everyday.
How can I change the CAPTCHA settings to stop these spambots? I use the question CAPTCHA - it is the easiest to use and install and I want to keep it without adding new CAPTCHAs.
Is there another extension I can add which will limit the spambots creating a new account?
These bots only create new user pages - can I block all users from adding external links - but only to user pages?

It is not very clear upfront, with a quick preliminary 2 minute reading of this extension, what this extension is capable of doing.

I would like to add an example or two in the introduction as soon as someone answers affirmatively that this extension can help me.

Thank you in advance! Igottheconch (talk) 11:03, 9 May 2013 (UTC)Reply

Would something like this work to stop users from adding html links on their user pages?
http://en.wikipedia.org/wiki/Special:AbuseFilter/483
how would I change it to work?
Thank you! 158.74.35.10 21:31, 10 May 2013 (UTC)Reply
I am so tired of how shitty mediawiki is as far as spam. There truly is no good solution to this. This is the biggest weakness of the software. Brownfloor (talk) 16:35, 18 May 2013 (UTC)Reply
The infamous filter 17 on Uncyclowikia might help. Change the namespace line from excluding UnNews to including only User, and add a condition on user_editcount so that users who have been around for a while without being b& can include whatever citations they might need in their respective biographies. --Damian Yerrick (talk) 04:10, 13 August 2013 (UTC)Reply
From my understanding what you are asking for, you can try this:
!("autoconfirmed" in user_groups) &
article_namespace == 2 &
(count("http://", string(added_lines)) != count("http://deadrisingwiki.com", string(added_lines))) &
((count("http://", string(added_lines))) > count("http://", string(removed_lines)))

~ UltimateSupreme 18:17, 15 August 2013 (UTC)Reply

RangeBlock durations

I have a spambot filter that I've set "Block the /16 range from which the user originates" and the filter has been creating the blocks, but is setting the block for an indefinite peroid, I have looked everywhere I can think of to change this setting to no avail. Hope someone knows. Mlpearc (powwow) 21:16, 10 May 2013 (UTC)Reply

As of now, this isn't possible.~ UltimateSupreme 14:54, 29 July 2013 (UTC)Reply

I too am seeing this issue. It looks like it's just a bug in the message. Check the Special:BlockList shows that it is not blocked indefinitely. Al Johnson (talk) 23:21, 11 May 2014 (UTC)Reply

MW 1.16

For anybody else in the sad position to have to install this on 1.16, the most recent version that works is c36169004e09db10eecd37f4a056bc0c1aa28be1 from 2011-07-13. Matma Rex (talk) 12:37, 26 July 2013 (UTC)Reply

Bug Report

In the abuse_filter_log table, afl_namespace is created as a signed tinyint. Since namespaces are ints, not tinyints, in MediaWiki, this will form incorrect links in the log if the namespace ID is higher than 127. – RobinHood70 talk 00:12, 22 August 2013 (UTC)Reply

filed under bugzilla:60622 --se4598 (talk) 17:40, 30 January 2014 (UTC)Reply

Tor_exit_node variable not available

The tor_exit_node variable is not available on Wikipedia and Wikia. Why?

Problem when editing page sections

Lsilverman (talk) 18:59, 19 May 2014 (UTC) If a user edits only a section of a page, it seems that the entire page's wikitext is evaluated against the filters. In the case where the violated filter prohibits the user from saving the page, the user can get stuck -- they've made a number of edits within the visible section, but cannot save due to a violation elsewhere in the document. They can't see or find the violation and would have to save their text in a text editor or similar, go fix the rule violation, then return.Reply

Is there a way around this?

The variables "added_lines", "removed_lines", "added_links", "removed_links" should only check the edited area.--Baumgeist (talk) 06:12, 24 August 2015 (UTC)Reply

Some suggested filters would be really useful

For someone setting up a small wiki, it's frustrating to see that there are no suggested or default filters at all. A link to other wiki's with thousands of filters is not useful.

Suggested/default filters would be useless, since the spammers would know them to. If you want this extension to work, you have to develop your own filters.--Baumgeist (talk) 06:06, 24 August 2015 (UTC)Reply

Mark as deleted / Enable this filter

Hi!
There is a boolean option "Mark as deleted" and another boolean option "Enable this filter". What is actually the difference between those options? One of them seems to be superflouos. -- seth (talk) 10:51, 31 May 2014 (UTC)Reply

Deleted filters are not shown by default one the list of filters, not activated ones are. Thus I guess deleted filters are meant to be archived, while deactivated filters are meant to be worked on until they do what they are supposed to.--Baumgeist (talk) 06:10, 24 August 2015 (UTC)Reply

AbuseFilter revert

Hey, I'm wondering how to user AbuseFilter revert. It asks me for a starting and ending date but I've tested multiple date format without success. It think it would be useful to document that. Thank you --78.229.54.104 11:12, 28 June 2014 (UTC)Reply

AbuseFilter help

Hello. I am Superdadsuper an Administrator on Biblicalapedia, an online biblical-history wiki that runs on a MediaWiki installation hosted on Wikia. I was wondering if anyone knew how (and perhaps create it for me) to make this regex script on the AbuseFilter, automatically disallow edits for this. Should this be done n the actual code or is it doable in the management tool? Can someone also make the user rights of sysop, bots, and the vstf exempt from this. Please make a fork of this code instead of editing the version pasted so my work is not damaged. Thanks, Superdadsuper, Biblicalapedia Administrator and Bureaucrat.

action==createaccount preventable?

While the extension seems to know this variable, it doesn't seem to be of any use - I can't prevent IP-ranges from creating accounts. --MBq (talk) 16:18, 4 January 2015 (UTC)Reply

filter to affect anons

I want to make an abuse filter which only triggers for an anonymous user to prevent them adding categories to mainspace articles. I've tried "user_groups == null" which doesn't work. Any help is appreciated... --81.131.81.92 12:15, 30 January 2015 (UTC)Reply

You can use "! (user_groups contains 'user')" to capturing anonymous users. --*devunt (talk) 12:34, 30 January 2015 (UTC)Reply
Thanks. If possible, can you check this filter is correct? I want to be able to disallow anonymous users from adding categories to articles (due to vandalism problems from such users):

!(user_groups contains "user") & ("[[Category:.*?]]" in added_lines)

If I need to tweak this, let me know. --81.131.81.92 12:53, 30 January 2015 (UTC)Reply
Use added_lines irlike "[[Category:.*?]]" insteads of in --*devunt (talk) 13:01, 30 January 2015 (UTC)Reply
Thanks devunt! Works fine now. :) --81.131.81.92 13:15, 30 January 2015 (UTC)Reply

Condition limit

The popularity of abuse filters on enwiki has apparently exceeded what the extension can handle, at least under it's current configuration. We have some filters that only have so many hits, but when batch tested against recent changes we see many more edits that should have been tripped. Right now at en:Special:AbuseFilter the percentage of recent actions that reached the condition limit (1,000) is at about 9%. Does this indeed cause some filters to fail? What would be the potential implications of increasing the condition limit? Is it purely for performance reasons? It seems that since the AbuseFilter was first introduced, the machinery the site runs on must have become more powerful, with more resources to expend. MusikAnimal (talk) 01:22, 5 February 2015 (UTC)Reply

I totally agree with MusikAnimal, it's a shame this post didn't get an answer. --UAwiki (talk) 01:13, 7 January 2016 (UTC)Reply

Filter question

Hi. I'm working on a filter that will disallow an edit if a certain number of bytes are added to the page without a proper reference tag. However, the condition for this in my filter ((new_size > 275)) triggers when more than 275 bytes are removed which is undesirable: is there a way to ensure that the condition only checks byte additions, not byte removal? Thanks for a quick reply! --213.120.34.217 21:48, 20 March 2015 (UTC)Reply

Just bumping in case this was possibly missed. If there is no solution, then I can just work around it with another condition. --213.120.34.217 11:47, 21 March 2015 (UTC)Reply
Please give the link if it is not a private filter. --Mahitgar (talk) 13:27, 29 March 2015 (UTC)Reply
It's a private filter. But it doesn't really matter, the filter won't be used on the community in question. There's a workaround in my filter in any case to get around the issue with new_size counting byte removal, but doesn't matter. --213.120.34.217 16:06, 29 March 2015 (UTC)Reply
"new_size" should be the size of the page after editing. So if you want to check if a certain number of bytes are added, you could use something like this: (new_size > (275 + old_size)) or this: (edit_delta >= 275) (edit_delta is negative, if bytes are removed).--Baumgeist (talk) 05:57, 24 August 2015 (UTC)Reply

Unable to load on MediaWiki 1.25.1

[Sun Jul 26 06:44:14.419619 2015] [:error] [pid 4902] [client [snip]:54203] PHP Fatal error:  Call to undefined method ObjectCache::getMainStashInstance() in /var/lib/mediawiki-1.25.1/extensions/AbuseFilter/AbuseFilter.hooks.php on line 281, referer: https://[snip]/mediawiki/index.php/Main_Page

MediaWiki 1.25.1

PHP 5.5.9-1ubuntu4.11 (apache2handler)

MySQL 5.5.44-0ubuntu0.14.04.1

Server version: Apache/2.4.12 (Ubuntu)

Server built: Feb 4 2015 14:20:03

Any ideas appreciated. I'm running an updated version of Apache and PHP compared to the stock 14.04 version so I suspect this is the issue.

--Zerbey (talk) 16:30, 27 July 2015 (UTC)Reply

Making AbuseFilter and Extension:HitCounters

I would very much like to use both Extension:HitCounters and AbuseFilter, but they seem to be incompatible at the moment ([5]). Which of those extensions has to be changed to fix this problem? Is someone working on this?--Baumgeist (talk) 19:28, 26 August 2015 (UTC)Reply

Possible false positive

Somebody may want to double check that IP blocking, but that seems to be a false positive:

Thanks.—Teles «Talk to me˱M @ C S˲» 17:53, 23 October 2015 (UTC)Reply

Problems

I am having some issues on my wiki. I can create empty filters and enable/disable them but I can't do anything else. If I try it says,

Not Implemented

GET to /index.php/Special:AbuseFilter/2 not supported. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

This only happens when I try to edit the conditions. Any thoughts? 67.244.58.187 00:47, 9 April 2016 (UTC)Reply

Being handled in Topic:T23dyyih0ofjada5 --Ciencia Al Poder (talk) 21:15, 14 April 2016 (UTC)Reply

Bug: AbuseFilter seemingly triggers on OLD spam text when undoing page changes

Has anyone noticed this? I have not done any recent upgrades and have never seen this before.

When undoing spam, the abuse filter triggers even though the page text being reverted to is spam-free. I have to first edit and delete all the page content, save, than edit and paste back in the old (pre-spam) page text. When I do this, the abuse filter correctly does not trigger.

Also, I noticed that when viewing the pre-spam revision, it shows the spam version page text. But, when I go into edit mode, the pre-spam revision is correctly in the edit textarea. This makes me think its a MediaWiki or database corruption issue. Al Johnson (talk) 03:40, 27 June 2016 (UTC)Reply