Inmiddels heb ik de ConfirmEdit aan het werk gezien. De standaard-configuratie weigert het toevoegen van externe URLs, heb ik ontdekt.
Ik probeerde de URL "http://www.google.nl" toe te voegen aan een willekeurige pagina. Dit triggerde ConfirmEdit. Ik moest eerst een rekensom oplossen.
Standaard-situatie in ConfirmEdit.php:
/**
* Actions which can trigger a captcha
*
* If the 'edit' trigger is on, *every* edit will trigger the captcha.
* This may be useful for protecting against vandalbot attacks.
*
* If using the default 'addurl' trigger, the captcha will trigger on
* edits that include URLs that aren't in the current version of the page.
* This should catch automated linkspammers without annoying people when
* they make more typical edits.
*
* The captcha code should not use $wgCaptchaTriggers, but CaptchaTriggers()
* which also takes into account per namespace triggering.
*/
$wgCaptchaTriggers = array();
$wgCaptchaTriggers['edit'] = false; // Would check on every edit
$wgCaptchaTriggers['create'] = false; // Check on page creation.
$wgCaptchaTriggers['addurl'] = true; // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure
Nieuwe situatie:
$wgCaptchaTriggers = array();
$wgCaptchaTriggers['edit'] = true; // Would check on every edit
$wgCaptchaTriggers['create'] = true; // Check on page creation.
$wgCaptchaTriggers['addurl'] = true; // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure
Ik heb de 'edit' en 'create' op "true" gezet.
Als ik nu probeer te editen, zonder in te loggen, moet ik eerst een rekensom oplossen. Bijvoorbeeld:
86 - 8 =
Kortom, na een stevige doch opluchtende huilbui begin ik de configuratie voorzichtig te snappen.
En als ik het snap, moeten er veel meer mensen het kunnen snappen.
Bovenstaande configuratie betekent dat ook geregistreerde gebruikers verplicht zijn om rekensommetjes op te lossen. Maar ook hier heb ik inmiddels een aanpassing weten te maken.
Standaard-situatie in ConfirmEdit.php:
$wgGroupPermissions['*' ]['skipcaptcha'] = false;
$wgGroupPermissions['user' ]['skipcaptcha'] = false;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop' ]['skipcaptcha'] = true;
$wgAvailableRights[] = 'skipcaptcha';
Nieuwe situatie:
$wgGroupPermissions['*' ]['skipcaptcha'] = false;
$wgGroupPermissions['user' ]['skipcaptcha'] = true;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop' ]['skipcaptcha'] = true;
$wgAvailableRights[] = 'skipcaptcha';
Ik kan nu als gebruiker Daniel73 editen zonder dat ik een rekensom krijg.
Een probleem. Als ik probeer in te loggen met een fout wachtwoord, krijg ik géén rekensom. Maar in ConfirmEdit.php staat:
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure
Verderop in de configuratie staat:
/**
* Number of seconds after a bad login that a captcha will be shown to
* that client on the login form to slow down password-guessing bots.
*
* Has no effect if 'badlogin' is disabled in $wgCaptchaTriggers or
* if there is not a caching engine enabled.
*
* Default is five minutes.
*/
global $wgCaptchaBadLoginExpiration;
$wgCaptchaBadLoginExpiration = 5 * 60;
Ook met de (huidige) waarde 1 * 60 (1 minuut) krijg ik geen rekensom:
$wgCaptchaBadLoginExpiration = 1 * 60;
De 'badlogin' staat aan in $wgCaptchaTriggers, dus is blijkbaar "not a caching engine enabled". Hoe zet ik zo'n "caching engine" aan, als het probleem daaraan ligt?
Zonder deze functie hebben spambots nu de mogelijkheid om wachtwoorden te raden en accounts over te nemen - inclusief die van beheerders!
Mediawiki.org heeft een of meer pagina's over caching:
http://www.mediawiki.org/wiki/Manual:Configuration_settings#Cachehttp://www.mediawiki.org/wiki/Manual:CacheHeeft iemand enig idee wat ik zou moeten doen, als het probleem aan een cache ligt?
In elk geval is de McDrake Wiki een stapje verder. Hulp is welkom om die badlogin te activeren.