Extension:Antispam

**MediaWiki 拡張機能マニュアル**
Antispam by CleanTalk; リリースの状態: 安定
実装	利用者アクティビティ, ページの操作
説明	Client extension for cloud anti-spam service CleanTalk.org.
作者	Denis Shagimuratov
最新バージョン	2.4 (2023-07-28)
MediaWiki	1.29+
PHP	5.3+
データベースの変更	はい
ライセンス	GNU 一般公衆利用許諾書 2.0 以降
ダウンロード	GitHub: プロジェクトのページ; git リポジトリの URL [ヘルプ]; コミット履歴; ; 注:; 地域化の更新は; translatewiki.net からは提供されません。
	パラメーター $wgCTAccessKey; $wgCTCheckNoConnect; $wgCTServerURL; $wgCTAgent; $wgCTExtName; $wgCTAdminAccountId; $wgCTAdminNotificaionInteval; $wgCTShowLink; $wgCTSFW; $wgCTNewEditsOnly; $wgCTMinEditCount;
	追加する権限 cleantalk-bypass;
	使用するフック EditFilter; UploadVerifyFile; SkinAfterBottomScripts; TitleMove;

This page is a translated version of the page Extension:Antispam and the translation is 5% complete.

Outdated translations are marked like this.

The Antispam extension is a client-side application for a commercial cloud anti-spam service, cleantalk.org.

Features

Anti-Spam service

The CleanTalk Cloud Service provides automatic and invisible protection from spam for websites. CleanTalk analyzes user behavior and evaluates the parameters of a completed form.

When installed on your website, the Anti-Spam Module captures the behavior parameters of a visitor or a spambot. These parameters are being assessed, and the service decides to post the visitor's message or to define it as spam and reject it. Based on such checks, the service forms its list of email addresses used by spambots. Likewise, visitor registrations are being checked too. The service adds not only email addresses to the global blacklist but also IP addresses and domains of the websites that are promoted through spam mailout.

Spam Firewall feature

This option allows blocking spam bots before they access MediaWiki content. CleanTalk collects spam bots activity data on websites, and IP addresses of the most active spam bots are added to the Spam Firewall database. The service intercepts any HTTP(POST/GET) requests to a site and IP address it contains. If an IP address is included in the CleanTalk blacklist of most spam active IPs, it will get a special page; if it is a real visitor, then it proceeds to the site. That is completely transparent to the visitors. The results of Spam FireWall are logged and available in your control panel.

Real-Time Email Address Existence Validation

To validate that users sign up with their real email addresses, the CleanTalk server will perform email account existence checks using an SMTP response.

Private blacklist/whitelist

Automatically blocks comments and registrations from your private black IP/email address list. This option helps to strengthen the protection from manual spam or block unwanted user comments. You can add not only certain IP addresses but also a separate subnet to your blacklist. The extension allows blocking or whitelisting emails for registration using wildcards; for example, "*@mail.com" will block/allow every address ending on @mail.com.

Blocking users by country

The external service can be used to block comments and registrations from specific countries automatically.

Stoplist by words

Comments that contain specific words can be forbidden.

$1 スクリーンショット

World map of top spam
Analytics
Log contents
Account creation rejected

インストール

ダウンロードして、ファイルをextensions/フォルダー内のAntispamという名前のディレクトリ内に配置します。
以下のコードを LocalSettings.php ファイルの末尾に追加します:
```
wfLoadExtension( 'Antispam' );
```
Configure as required.
完了 – ウィキの「Special:Version」に移動して、拡張機能が正しくインストールされたことを確認します。

構成パラメーター

$wgCTAccessKey

To run extension get an access key at http://cleantalk.org/register?platform=mediawiki
Place the Access key in the LocalSettings.php with the variable $wgCTAccessKey.

$wgCTNewEditsOnly: Set as you wish true or leave at the default false.
$wgCTCheckNoConnect: Defaults to true
$wgCTServerURL: Defaults to http://moderate.cleantalk.org/api2.0
$wgCTAgent: Defaults to mediawiki-24
$wgCTExtName: Defaults to Antispam by CleanTalk
$wgCTAdminAccountId: Defaults to 1
$wgCTAdminNotificaionInteval: Defaults to 10800
$wgCTShowLink: Defaults to true
$wgCTSFW: Defaults to false
$wgCTMinEditCount: Defaults to 10

よくある質問

Should I change anything in the extension's settings or in my CleanTalk Control Panel when I switch my website from HTTP to HTTPS or vice versa?

No, the extension will work regardless of the protocol.

After installation, on creation of a test user, I get error:Fatal exception of type "Wikimedia\Rdbms\DBQueryError". How to fix?

Temporarily add:
require_once "$IP/extensions/Antispam/Antispam.php";
into LocalSettings.php, verify that the extension was loaded on the version page, then replace with:
wfLoadExtension( 'Antispam' );
Don't set the key in the extensions/Antispam/Antispam.php file, but in LocalSettings.php file as variable $wgCTAccessKey below the load instruction.

This extension is dependent on cleantalk.org, a commercial paysite. Are there any free options or alternatives?

The Antispam extension is specific to this one provider, which is non-free. There are hundreds of other real-time blocklists (RBLs) or DNS blocklists (DNSBLs), both paid and free; most target spam e-mail but a few target forum or blog comment spam. Extension:StopForumSpam uses stopforumspam.com to prevent comment spam, for instance. Another option is to download IP deny lists from any of a number of sources, and import them into MediaWiki using the maintenance/updateDenyList.php script.

But what about false positives? Is there any way to prevent the extension from submitting the username, email address and IP address of my legit users only to have them appear on cleantalk.org's public blocklists?

While the number of false positives is relatively low, this is a problematic issue. It's best to mitigate this risk by only invoking Antispam on new account creation and on new page creation by new or anonymous users.

Implement autoconfirmation and set $wgAutoConfirmAge to something reasonable. Give the 'cleantalk-bypass' permission to the bot, sysop and autoconfirmed groups by by setting {{ll|Manual:$wgGroupPermissions|$wgGroupPermissions]]['autoconfirmed']['cleantalk-bypass'] = true; and making the same change for other desired groups in LocalSettings.php .
Limit the extension to new page creation by setting $wgCTNewEditsOnly = true; in LocalSettings.php
The cleantalk.org web interface does provide a list of who and what has been blocked by the filter. It is possible to report false-positive or false-negative results there; this doesn't reinstate a wrongly-blocked edit or remove a wrongly-blocked IP from the Cleantalk lists, but it will temporarily whitelist the user on your own site.

I have multiple subprojects (such as en.example.wiki, fr.example.wiki, pt.example.wiki) for different topics or different languages. Will this extension work with this structure, or do I need to redesign the site to user www.example.wiki/en/PageName www.example.wiki/es/PageName and the like?

The extension will work regardless of your URL structure. The only limitation is that the Cleantalk server will remove the original domain and subdomain, replacing them with whatever domain name is tied to the ID specified in $wgCTAccessKey. This only affects the displayed blocklogs on the Cleantalk website; the extension will still work. Another option is to purchase multiple keys (one for each language subproject) but this does cost extra.