Manual:$wgSpamRegex/hu

Bármely, a változóban rögzített szöveggel („regexszel”) egyező szerkesztés wikispamként lesz értékelve és a szerkesztés elmentése nem lesz lehetséges. A $wgSpamRegex minden felhasználóra, még az adminisztrátorokra és bürokratákra is vonatkozik. A csoportonkénti szűrés a használatával lehetséges. A $wgSpamRegex a MediaWiki egyik leghatékonyabb spamszűrő funkciója. A beállítás nem blokkol minden spamet, de azok mennyiségét drámaian csökkentheti, miközben a jóindulatú szerkesztők emiatt nem szenvednek kárt. A $wgSpamRegex konfigurációja szabja meg a MediaWiki szövegfelismerésének módját, és annak eldöntését, hogy az spam-e.

Egy nagy példa
A következő példában szereplő beállítást érdemes kipróbálnod saját wikiden; a példawiki egy kis/közepes méretű weboldal, amely spammerek támadásának van kitéve. Illeszd be a következő kódot a -ba:

Az utolsó előtti sor végén nem szerepel a „|” jelölő; ennek oka, hogy a következő sor lezárja a kifejezést, valamint tartalmazza az „i” kapcsolót.

Ez a példa a Meta-Wiki spam-feketelistájáról származik, és gyakori, spamre utaló karakterláncokat tartalmaz, egyben a blokkoláshoz is segítség lehet. CSS-be rejtett spam

A szűrő használata a spamek megakadályozása
Itt találsz egy útmutatót. A $wgSpamRegex-szel való kísérletezés után teszteld az eredményt a próbalapodon. Figyelem! Gondoskodj az álpozitív eredmények kiszűréséről (például hasznos szerkesztések spamként való megjelölése); lásd alább az ÁLPOZITÍVOK KISZŰRÉSE! szakaszt.

A $wgSpamRegex-ben rögzített beállítás egy reguláris kifejezés (lásd a Wikipédia-szócikket és a [$wgSpamRegex PHP-útmutatót]). A fenti példában egy a PHP szintaxisával egyszerűsített, többsoros kifejezést láthattál. Ezzel a kifejezések rövidebbek, viszont bonyolultabbak lesznek.

Saját kifejezéseid megalkotásakor teszteld őket a PCRE Regex Evaluator oldalon (kattints a PCRE fülre).

Egyszerű példa
Alább egy még egyszerűbb példát láthatsz:

Tartsd észben: a cél eldönteni – a szerkesztés spam-e vagy sem? Ezzel a példával bármely, a „ ” karaktersort tartalmazó szerkesztés nemkívánatosnak lesz jelölve. A kezdő és záró „/” jelek a reguláris kifejezés szintaxisának részét képezik.

Több különböző szó/domain tiltása
Egészítsük ki a példánkat további spamek elfogásához:

A szavak közti „|” jel több spamnek jelölt szót is tilt, valamint a spammerek által reklámozott URL-címeket is megfogja.

A $wgSpamRegex minden közzétenni kívánt szövegre vonatkozik, ideértve az URL-címeket is; ezáltal egy bizonyos spammer ellen hatékony lehet a domaincímek blokkolása.

ÁLPOZITÍVOK ELKERÜLÉSE!
A hasznos szerkesztések spamnek jelölését nehéz elkerülni, ezt leginkább a következő rossz példával lehet szemléltetni:

Sok spammer szerkesztésében megtalálható a „cialis” („valami drog. Kit érdekel? Minket nem!”); a szűréshez kézenfekvő lehet a szó tiltása, azonban ezzel például a „specialista” szót sem lehet közzétenni. Ezt a hibát nagyon könnyű elkövetni; igyekezz a reguláris kifejezésben használt szavak megválogatását, mivel a cél a spammerek távol tartása a hasznos szerkesztők zavarása nélkül. Sok esetben megoldást jelenthet a „\b” beillesztése a kifejezés végeire, amely hosszabb szavakban figyeli az adott karakterlánc előfordulását, például:

Egyéb tippek
A reguláris kifejezések nagyon hatásosak. A $wgSpamRegex-ben foglalt kifejezések vizsgálata a teljes lapon, vagy az éppen szerkesztett szakaszban történik, nem csak az URL-ekben. Ezáltal szinte bármi nem kívánatos kifejezés tiltható, ha megfelelő kifejezést írsz hozzá (az álpozitívok kiszűrése érdekében a kifejezések legyenek minél specifikusabbak). A következő szakaszban azt mutatjuk be, hogyan használható az eszköz a CSS-be rejtett spamek ellen.

Egyezéskor mutatott üzenet
Alapesetben ha a $wgSpamRegex egyezést talál a lapon, a következő üzenet látható:


 * 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]

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 have made 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  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.