Extension talk:AbuseFilter

From MediaWiki.org
Jump to: navigation, search

Contents

Filters have no effect[edit | edit source]

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)


Possible postgres problem[edit | edit source]

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[edit | edit source]

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)

Throttling[edit | edit source]

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

Some problems[edit | edit source]

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)

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)

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)
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)

Proximity operators[edit | edit source]

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)

Beta status[edit | edit source]

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)

Documentation?[edit | edit source]

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)

Documentation shortcomings[edit | edit source]

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)

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

Installation is hard[edit | edit source]

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)

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)
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)


What to do in case of "unexpected T_STRING" error[edit | edit source]

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)

Tags[edit | edit source]

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[edit | edit source]

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

Adapt I/O for augmenting templates?[edit | edit source]

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)

How to import Wikipedia abuse filter?[edit | edit source]

Want to use it in my local wiki.

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

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)

MediaWiki version[edit | edit source]

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

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)

Images & Special characters on same page producing fatal error in AbuseFilter[edit | edit source]

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)

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)

Conflicts with TemplateFormEditor[edit | edit source]

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)

AbuseFilter actions[edit | edit source]

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)

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

Only one edit per page[edit | edit source]

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)

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)
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)
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)
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)
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)
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)

Examples of Filters[edit | edit source]

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[edit | edit source]

  • 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)

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)

Problem with Class 'Html' not found Faltal Error[edit | edit source]

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)

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)
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)

Global Abuse Filter[edit | edit source]

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)

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)

Apply filters[edit | edit source]

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)

Xml:hidden[edit | edit source]

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)

Logic tips for non-coders[edit | edit source]

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/RulesFormat? --Chriswaterguy 04:10, 23 December 2011 (UTC)

Verbose log?[edit | edit source]

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)

SQLite database error[edit | edit source]

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))

Additional information: MediaWiki 1.18.1, PHP 5.3.10

Disallow + block[edit | edit source]

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)

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)

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)

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)
I encountered this same bug. See thread at bottom. Dcoetzee (talk) 02:15, 11 April 2012 (UTC)

user_age in "Examine individual changes"[edit | edit source]

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)

A few more options...[edit | edit source]

  • 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[edit | edit source]

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)

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)

How can I use createaccount?[edit | edit source]

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)

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)

Database error[edit | edit source]

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)

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

Username whitelist on registration[edit | edit source]

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)

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)

Not blocking[edit | edit source]

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)

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)

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)

Suggestion: user agent[edit | edit source]

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)

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)

Not working at all[edit | edit source]

  • URL: http://wikibound.info/WikiBound
  • MediaWiki 1.20alpha (820ed86)
  • PHP 5.3.2-1ubuntu4.11 (apache2handler)
  • MySQL 5.1.41-3ubuntu12.10
  • AbuseFilter (aed6dd0)

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).

Did you remember to set up the $wgGroupPermissions?--Jasper Deng (talk) 19:35, 6 May 2012 (UTC)
That I did. I mean, I did recall to do it, and still nothing happens. Bud0011 (talk) 19:58, 6 May 2012 (UTC)
What were your custom groups?--Jasper Deng (talk) 01:36, 7 May 2012 (UTC)
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)
Perhaps place these after you include the AbuseFilter files?--Jasper Deng (talk) 02:11, 7 May 2012 (UTC)
Sorry, but I've tried before and after. Bud0011 (talk) 23:13, 7 May 2012 (UTC).
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)
Yeap, here it is. Bud0011 (talk) 00:09, 9 May 2012 (UTC)
Should be working fine...--Jasper Deng (talk) 00:27, 9 May 2012 (UTC)
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)

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)

Why is blocking indefinate?[edit | edit source]

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[edit | edit source]

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)

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

Remove AbuseFilter updates from Special:RecentChanges?[edit | edit source]

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

Thanks.

$wgAbuseFilterBlockDuration for IP addresses[edit | edit source]

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)

$wgAbuseFilterCentralDB[edit | edit source]

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)

Tor_Exit_Node[edit | edit source]

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)

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

How can I remove logs?[edit | edit source]

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)


some Problems[edit | edit source]

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[edit | edit source]

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)

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)

The problem is deleting pages.[edit | edit source]

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[edit | edit source]

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)

Verify extension requirements[edit | edit source]

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)

Stop creation of accounts or external website links on user pages only[edit | edit source]

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)

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)
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)
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)
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)

RangeBlock durations[edit | edit source]

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)

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

MW 1.16[edit | edit source]

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)

Bug Report[edit | edit source]

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)

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

Tor_exit_node variable not available[edit | edit source]

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