Manual:$wgSpamRegex/fr

Tout texte ajouté à une page du wiki correspondant à cette expression régulière (ou "regex") de localsettings.php sera reconnue comme de la pollution Wiki et l'édition sera bloquée.

$wgSpamRegex est une des fonctionnalités anti-pollusion intégrée les plus efficaces. Elle ne bloquera pas toutes les pollutions, mais pourra les réduire significativement, presque sans aucun impact négatif pour les utilisateurs légitimes. Les paramètres de configuration de $wgSpamRegex contrôleront comment MediaWIki examine le texte des contributions et détermine si ce sont ou non des pollutions.

Si votre expression régulière de filtrage des pollutions échoue sans bruit, elle peut nécessiter plus de mémoire! Voyez

Un gros exemple
L'exemple suivant est un bon paramètre à essayer sur votre wiki, s'il est de taille moyenne/petite et souffre de nombreuses attaques polluantes. Copiez ce qui suit dans votre fichier LocalSettings.php: Remarquez que les ligens 2 à la fin n'ont pas le "|" à la fin de la chaîne. Ceci est parce que la ligne suivante termine l'expression régulière avec la marque fermante / suivie de la bascule "i".

Cet exemple incorpore les mots clés polluants classiques (certains pris de Liste noire des pollueurs de Meta-Wiki) et aussi des techniques pour bloquer les pollutions cachées par CSS.

Utiliser des expressions régulières pour bloquer les pollutions
Expérimentez avec le paramètre $wgSpamRegex, et testez avec quelques éditions sur votre bac à sable, pour voir ce qui est bloqué. Mais attention! Veillez à éviter les faux positifs c.à.d. les éditions légitimes correspondant à tort; voyez ÉVITER LES FAUX POSITIFS! ci-dessous.

Le paramètre que vous assignez à $wgSpamRegex est une expression régulière (voyez l'article de Wikipedia et le manuel PHP sur les expressions régulières). L'exemple ci-dessus montre une expression régulière construite sur plusieurs lignes, utilisant la syntaxe point de PHP pour concaténer les chaînes. Cela rend les expressions régulières longues plus lisibles, mais aussi un peu plus compliquées.

Si vous créez votre propre expression régulière, vous pouvez vouloir les tester dans un évaluateur de regex PCRE (cliquez sur l'onglet PCRE sur cette page).

Exemple simple
Voici un exemple beaucoup plus simple:

Rappelez-vous que l'idée est de décider - Est-ce une pollution ou non? Avec cet exemple, tout texte contributif contenant 'buy-viagra' sera identifié comme de la pollution. Les symboles '/' au début et à la fin font partie de la syntaxe de l'expression régulière.

Bloquer plusieurs différents mots/domaines
Étendons notre exemple pour essayer de correspondre à d'autres types de pollution:

Utilisant un symbole '|' entre les mots, l'exemple ci-dessus bloquera différents mots polluants différents, et aussi des noms de domaine qui sont promus par les pollueurs.

La $wgSpamRegex est appliquée à tous les textes contributifs, incluant les pollutions comme les liens URLs. Ainsi, le blocage de noms de domaine peut être un moyen efficace de se débarrasser d'un pollueur particulier.

ÉVITER LES FAUX POSITIFS!
Éviter les faux positifs est le vrai défi ici, et le mieux est de l'illustrer par un mauvais exemple:

Beaucoup de pollueurs parlent de 'cialis' (une sorte de drogue) et vous pouvez donc être tentés de faire correspondre ce mot à une pollution, mais cela empêchera également les utilisateurs de mentionner le mot 'specialist.' Il est très facile de faire ce genre d'erreur. Veillez au paramétrage de vos expressions régulières. Vous voulez arrêter les pollueurs sans gêner vos utilisateurs.

Autres trucs d'expression régulière
Les expressions régulières sont très puissantes. La correspondance $wgSpamRegex s'applique à tous les textes de la page ou de la section éditée, pas qu'aux URLs. Cela vous permet de bloquer tout ce que vous n'aimez pas, si vous arrivez à trouver une expression régulière qui y correspond (soyez aussi précis que possible pour éviter les faux positifs). Dans la section suivante sur la pollution cachée par CSS, nous utilisons cet outil.

Messages correspondant à de la pollution
Normally when the $wgSpamRegex setting matches some spam, the following message is displayed:


 * The page you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.
 * The following text is what triggered our spam filter: [word/domain name which was blocked]
 * The following text is what triggered our spam filter: [word/domain name which was blocked]

This text can be changed, and is located on two editable wiki pages in the MediaWiki namespace. Click 'Special Pages' -> 'Wiki data and tools: System Messages', type 'spampro' into the 'Filter by prefix:' field and click 'Go'. If you get 'View Source' instead of 'Edit' on the top tab, then you don't have permission to edit. You need to log in as an sysop user (or the WikiSysop user which you configured during installation).

'$1' in MediaWiki:Spamprotectionmatch displays the failed edit's regex match that tripped the spam filter. Delete '$1' if you want it hidden.

Displaying/Hiding the matched text
If you've made a regex which is too restrictive, or you havemade some other mistake in the setting, then you may get false positives. Indeed the full example above might match legitimate text in some rare circumstances (maybe your users really do want to talk about buying Viagra). By displaying the text which matched, the MediaWiki:Spamprotectionmatch message helps to reduce problems caused by false positives. It allows your users to accurately report problems to you, about your $wgSpamRegex setting. It also allows them to figure out a workaround, so they can continue with their wiki editing.

Unfortunately it's also a very useful bit of information for spammers visiting your site. Some spammers are automated bots, so they won't be seeing this information anyway, however many spammers (believe it or not) are humans. These humans could go to the trouble of looking at the matching information, and trying to devise a workaround (e.g. just missing out the domain name that you have blocked, but linking to various other domains). It's difficult to know how prevalent this kind of behavior is, but if you wanted to make life more difficult for them. You could hide the spam matching information by simply setting your MediaWiki:Spamprotectionmatch message as empty. You should only do this if you are very aware of the above points about false positives, and have carefully designed your regexp to avoid them.

CSS Hidden Spam
MediaWiki is quite permissive when it comes to HTML tags, and CSS style definitions (see Help:HTML in wikitext on Meta-Wiki)

This has given spammers the opportunity to invent a sneaky trick to hide their spam from view. It doesn't show up on your pages, but it does show up in your edit boxes, and the changes show up in your 'recent changes' display. As such it causes confusion to your legitimate users, and that's before you consider the effects of helping a spammer by hosting their links. Generally 'CSS Hidden Spam' is all bad. Just because you can't see it (easily), doesn't mean you can ignore it.

The problem was identified by the folks at chongqed.org in 2005, but has got a lot worse in 2006, to the point where it seems most mediawiki spammers are using this trick.

We can use a regular expression to prevent the CSS tricks which they are using. Two of these are incorporated in the full example above (combined using the '|' symbol):

To prevent CSS hidden spam of the form :

To prevent CSS hidden spam of the form style="display:none;":

For a slightly more strict setting you might prefer to disallow various attributes of the style tag altogether:

...but you may find this starts to restrict your users more than you would like.

Block ALL external links
You can block all external links by using this regex: This is extremely restrictive to the wiki's legitimate users, as they cannot link to any external site anymore. It is a poor solution to the spam problem, although it is marginally better than a complete lock down.

If you are going to use this, make sure your 'MediaWiki:Spamprotectiontext' page has an explanation of what you have done.

Limit external links to 100
You can limit the total number of external links allowed per page, to say 100, with this

If you do this, make sure your 'MediaWiki:Spamprotectiontext' page has an explanation of what you've done.

pcre.backtrack_limit
If your spam filter regex quietly fails, it may need more memory! Or you may need to write your regex better so it does not waste itself: making * ungreedy by adding a ? to it, like so *?, can greatly help efficiency! Test your home brewed regexes in a PCRE Regex Evaluator (click the PCRE tab there).

PHP 5.2.x introduced pcre.backtrack_limit with default 100000 (less than 100K). I think that is too low and trips up the regex. See stronk7 at moodle dot org's 13-Sep-2007 comment (Find '13-Sep-2007') at http://us.php.net/manual/en/ref.pcre.php. Try adding the following line to LocalSettings.php:

I don't know what value is appropriate. 8M works for me and is lifted from paragraph 4 of Wikipedia's Perl Compatible Regular Expressions article intro. Someone who knows more please adjust that and comment.