MediaWiki/Spam

From DreamHost

< MediaWiki

Blocking Spam

See main article.

Using a CAPTCHA

By using a CAPTCHA, one can prevent automated bots from adding things to the wiki. Examples of MediaWiki CAPTCHA plugins are reCAPTCHA and ConfirmEdit.

Locking Down the Wiki

There are sometimes legitimate reasons to lock down a wiki. You can shut down open account registration and disallow non user edits.

To do so edit LocalSettings.php, AFTER the line:

require_once( "includes/DefaultSettings.php" );

Disallow edits by unregistered users:

$wgGroupPermissions['*']['edit'] = false; 
$wgShowIPinHeader = false;

Disallow account creation:

$wgGroupPermissions['*']['createaccount'] = false;

Mixed Techniques

A middle road is also possible. The following methods can be used to discourage spam.

.htaccess for the domain contains:

Options -indexes

# Very VERY few legitimate clients leave their user agent field blank, and those that do should fix this behavior. 
# You can stop spam at the door by forbidding access to your wiki to anyone connecting with a blank user agent. 
# If you don't already have a .htaccess file in the root of your site, create one. Then edit .htaccess and add this:

SetEnvIf User-Agent ^$ spammer=yes     # block blank user agents

Order allow,deny
allow from all           
deny from env=spammer

<Files .htaccess>
order allow,deny
deny from all
</Files>

LocalSettings.php has the following added, just before the end:

# Block CSS Hidden Spam from div tags. Lots of wiki spam is hidden in specially constructed div tags. 
# Mediawiki allows div tags, so I use this solution which allows most of the tags but 
# blocks them if they use any attributes which may be used for hiding and have little or no use in a wiki.

$wgSpamRegex = "/\<.*style.*?(display|position|overflow|visibility|height)\s*:.*?>/i";

# From: http://meta.wikimedia.org/wiki/Preventing_Access
# This snippet prevents editing from anonymous users
# Users will still be able to read the page and can view the source by using Special:Export/Article name.
# Note that you have to add this to the end of the LocalSettings.php file, just above the closing

$wgGroupPermissions['*']['edit'] = false;

Caution: The following was tried initially, but it caused database errors:

# From includes/DefaultSettings.php
# Should editors be required to have a validated e-mail
# address before being allowed to edit?
# Commented out because SQL errors started, after 1st install try.
# $wgEmailConfirmToEdit=true;