Manual:$wgSpamRegex/cs

Jakýkoli text přidaný na wiki stránku odpovídající tomuto regulárnímu výrazu (nebo "regulárnímu výrazu") bude rozpoznán jako Wiki spam a úpravy budou zablokovány. $wgSpamRegex ovlivní všechny skupiny uživatelů. Dokonce i členové uživatelských skupin sysop a byrokrati nebudou mít povoleno uložit text, pokud odpovídá $wgSpamRegex. Pomocí můžete nastavit pravidla, která vám také umožní filtrovat podle skupin! $wgSpamRegex je jednou z nejúčinnějších integrovaných funkcí proti spamu MediaWiki. Nezablokuje veškerý spam, ale může dramaticky snížit spam, téměř bez negativního dopadu na legitimní uživatele. Konfigurační nastavení $wgSpamRegex bude řídit, jak mediawiki zkoumá text příspěvků a určuje, zda jsou příspěvky spamem nebo ne.



Velký příklad
Následující příklad je dobré nastavení pro vyzkoušení na vaší wiki, pokud se jedná o středně/malou wiki trpící spamovými útoky. Do souboru vložte následující:

Všimněte si, že předposlední řádek nemá "|" na konci řetězce. Je to proto, že další řádek ukončuje regulární výraz uzavírací obálkou / následovanou přepínačem "i".

Tento příklad zahrnuje běžná klíčová slova pro spam (některá převzata z Meta-Wiki's Spam Blacklist) a také techniky pro blokování CSS skrytého spamu.



Použití regulárních výrazů k blokování spamu
Zde je průvodce regulárními výrazy. Experimentujte s nastavením $wgSpamRegex a vyzkoušejte některé úpravy na stránce SandBox, abyste viděli, co je blokováno. Ale pozor! Dbejte na to, abyste se vyhnuli falešným poplachům, tj. nesprávné shodě legitimních úprav, viz Vyhnout se falešným poplachům níže.

Nastavení, které přiřadíte $wgSpamRegex, je regulární výraz (viz článek na Wikipedii a příručka PHP o regulárních výrazech). Výše uvedený příklad ukazuje regulární výraz, který se vytváří na několika řádcích, pomocí syntaxe PHP tečka ke zřetězení řetězců. Díky tomu je tento dlouhý regulární výraz kompaktnější, ale také o něco složitější.

Pokud vytvoříte své vlastní regulární výrazy, možná je budete chtít otestovat v PCRE Regex Evaluator (klikněte na záložku PCRE na této stránce).



Jednoduchý příklad
Zde je jednodušší příklad:

Pamatujte, že myšlenkou je rozhodnout - Je to spam: ano nebo ne? V tomto příkladu bude jakýkoli text příspěvku obsahující ' ' odpovídat jako spam. Symboly '/' na začátku a na konci jsou součástí syntaxe regulárního výrazu.



Blokování několik různých slov/domén
Rozšiřme náš příklad, abychom se pokusili porovnat více druhů spamu:

Použití '|' symbol mezi slovy, výše uvedený příklad zablokuje několik různých spamových slov a také některá doménová jména, která jsou propagována spammery.

$wgSpamRegex se použije na veškerý přidaný text, včetně adres URL spamových odkazů. Jako takové může být blokování doménových jmen velmi efektivním způsobem, jak se zbavit konkrétního spammeru.



Vyhněte se falešně pozitivním výsledkům
Vyhnout se falešným pozitivům je zde skutečnou výzvou a nejlépe to ilustruje špatný příklad:

Spousta spammerů ráda mluví o ' ' (nějaký druh drogy. Koho to zajímá? ne nás!), a tak byste mohli být v pokušení označit toto slovo za spam, ale tohle také zabrání uživatelům zmiňovat slovo ' .' Je velmi snadné udělat takovou chybu. Buďte opatrní s nastavením regulárního výrazu. Chcete zastavit spammery, aniž byste obtěžovali své uživatele. Tento problém lze v mnoha případech překonat zahrnutím vzoru hranice slova "\b" před a za jakákoli slova, která by mohla být obsažena ve větším slově, např.



Další tipy pro regulární výrazy
Regulární výrazy jsou velmi silné. $wgSpamRegex shoda se použije na veškerý text stránky nebo sekce, která se upravuje, nejen na adresy URL. To vám dává možnost zablokovat vše, co se vám nelíbí, pokud dokážete vypracovat dobrý regulární výraz, který tomu bude odpovídat (buďte co nejkonkrétnější, abyste se vyhnuli falešným poplachům). V následující sekci CSS Hidden Spam využíváme tento nástroj.



Zpráva o spamu
Normálně, když nastavení $wgSpamRegex odpovídá nějakému spamu, zobrazí se následující zpráva:


 * Stránka, kterou jste chtěli uložit, byla zablokována spamovým filtrem. To je pravděpodobně způsobeno odkazem na externí web na černé listině (blacklist).


 * Následující text spustil náš spamový filtr:

[slovo/název domény, které bylo zablokováno]

Tento text lze změnit a nachází se na dvou upravitelných wiki stránkách ve jmenném prostoru MediaWiki. Klikněte na 'Speciální stránky' -> 'Data a nástroje Wiki: Systémové zprávy', zadejte 'spampro' do pole 'Filtrovat podle prefixu:' a klikněte 'Jít'. Pokud se na horní kartě zobrazí 'Zobrazit zdroj' místo 'Upravit', nemáte oprávnění k úpravám. Musíte se přihlásit jako uživatel sysop (nebo uživatel WikiSysop, kterého jste nakonfigurovali během instalace).

'$1' v MediaWiki:Spamprotectionmatch zobrazuje shodu regulárního výrazu neúspěšné úpravy, která aktivovala spamový filtr. Pokud chcete '$1' skrýt, smažte.



Zobrazení/skrytí shodného textu
Pokud jste vytvořili regulární výraz, který je příliš omezující, nebo jste udělali jinou chybu v nastavení, můžete získat falešně pozitivní výsledky. 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 :

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
PHP since version 5.3.7 has a pcre.backtrack_limit which defaults to 1000000 (1M). However this may still be too low. Try adding the following line to your "LocalSettings.php" file:

If this still not enough you may gradually increase this limit until it fits you wikis actual requirement.