Sommaire des tutoriels pour integrateur

Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack

Le site : Accueil - Annuaire - Blog - Forum - Outils - Utilisateur
Le FTP : Consulter les fichiers partagés sur le FTP
Le Redmine : Consulter le Redmine

Maintenance et sécurité de Mediawiki

Scripts de maintenance et scripts SQL pour Mediawiki

Scripts de maintenance et scripts SQL pour Mediawiki.

Sauvegarder la base de données de Mediawiki

Sauvegarder la base de données de Mediawiki.

Sécurité de MediaWiki

Manuel de sécurité

Manuel - Sécurité : https://www.mediawiki.org/wiki/Manual:Security
@suivre

Connaître l'IP d'un utilisateur avec l'extension CheckUser

CheckUser est une extension qui permet à un utilisateur avec l'autorisation checkuser de vérifier quelles IP sont utilisées par un nom d'utilisateur donné et quels noms d'utilisateur sont utilisés par une IP donnée, sans avoir à exécuter des requêtes directement à la base de données.

Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:CheckUser
Télécharger CheckUser : https://github.com/wikimedia/mediawiki-extensions-CheckUser/archive/master.tar.gz
Placer les fichiers téléchargés dans /extensions/CheckUser/

Activer l'extension depuis LocalSettings.php
WfLoadExtension('CheckUser');

Empêcher et nettoyer le spam

Combattre le spam sur un wiki mediawiki

Les wikis peuvent devenir une cible pour les spammeurs.
Des faux comptes utilisateurs peuvent être créés avec des noms étrange.
L'objectif des spammeurs est souvent de mettre en avant un site internet, des produits, une marque.
Un vandale peut essayer de spammer en exécutant un bot pour créer, modifier, déplacer, supprimer des pages à une vitesse élevée, ou encore, télécharger des images importunes.
Un vandale peut tenter de modifier des modèles utilisés pour affecter un grand nombre de pages. Protéger les modèles les plus couramment utilisés listés depuis la page spéciale : Special: MostLinkedTemplates
De nombreuses solutions permettent de protéger MediaWiki du spam et du vandalisme.

Exiger un login et / ou un captcha sur certaines opérations, telles que des modifications, l'ajout de liens externes ou la création d'un nouvel utilisateur.
Bloquer les modifications à partir d'adresses IP en liste noire connues ou d'IP qui exécutent des proxies ouverts.
Bloquer les modifications qui ajoutent des mots clés non désirés ou des liens externes non désirés prédéfinis.
Liste blanche des éditeurs connus tels que les Administrateurs, les Bureaucrates, les contributeurs réguliers.

Différentes méthodes peuvent être utilisées pour tenter de limiter le nombre d'éditions de spam, les robots et les proxy ouverts tout en limitant les éventuelles perturbations causées aux utilisateurs légitimes du site.

Les fonctionnalités de défense ne sont pas activées par défaut.
Noter qu'aucune des solutions présentée ne peut être considérée comme complètement anti-spam.
L'administrateur du wiki doit s'assurer d'une veille régulière. Visiter régulièrement la page des modifications récentes.

Certains administrateurs pensent que verrouiller le wiki est la meilleure solution au spam.
C'est une mauvaise solution et une solution paresseuse car vous introduisez quelque chose qui dérange massivement les utilisateurs réels.
Le fait de devoir choisir un nom d'utilisateur et un mot de passe est très pénible pour de nombreuses personnes.
Le wiki doit être librement et ouvertement éditable.
Cette approche de «sécurité souple» est l'une des principales forces du concept wiki. 

Le manuel officiel de Mediawiki : Apprendre comment lutter contre le spam dans votre wiki mediawiki.

Premières réponses en cas de spam

# Bloquer l'accès le temps de mettre en place les correctifs de défense et de nettoyage.

Bloquer certaines pages en non-modifiable

# Bloquer certaines pages en non-modifiable comme par exemple la page d’accueil.

Source vers le manuel : https://www.mediawiki.org/wiki/Manual:Administrators#Protection

Interdire l'édition aux utilisateurs anonymes

Interdire l'édition aux utilisateurs non enregistrés qui restent anonymes. Les robots adaptés ont encore la possibilité de créer des comptes et de poster. Cette solution n'est pas optimale.

# Renseigner la ligne suivante avec la valeur false dans le fichier LocalSettings.php.
$wgGroupPermissions['*']['edit'] = false;

Exiger une confirmation du mail après une création de compte

# Renseigner la ligne suivante avec la valeur true dans le fichier LocalSettings.php.
$wgEmailConfirmToEdit = true;

Interdire la création de nouveaux utilisateurs

L’administrateur peut toujours aller sur la page Special:UserLogin pour créer des comptes utilisateurs.
# Renseigner la ligne suivante avec la valeur false dans le fichier LocalSettings.php.
$wgGroupPermissions['*']['createaccount'] = false;

Renommer un utilisateur

L'extension Renameuser fournit une page spéciale qui permet aux utilisateurs autorisés de renommer des comptes d'utilisateurs.
Cela entraînera la mise à jour des historiques de page.

Manuel : https://www.mediawiki.org/wiki/Extension:Renameuser
Télécharger : https://github.com/wikimedia/mediawiki-extensions-Renameuser/archive/master.tar.gz
Placer les fichiers dans un répertoire nommé Renameuser dans vos extensions/.

Ajouter le code suivant au bas de votre LocalSettings.php :
WfLoadExtension('Renameuser');

Passer le site hors ligne

Passer le site hors ligne le temps de corriger la base de données.

Captcha

L'objectif d'un captcha est de produire un casse-tête unique pour éviter les soumissions automatisées.
Un captcha tente de distinguer les utilisateurs réels et humains par opposition aux robots qui sont des systèmes automatisés.
Le captcha demande à l'utilisateur de résoudre une tâche qu'un programme informatique ne saurait pas résoudre sans intervention humaine.

Faiblesses du captcha

Les CAPTCHA basés sur l'image présentent quelques vulnérabilités.
Les robots utilisant la reconnaissance optique de caractères peuvent les craquer, et la seule défense est de rendre les images plus difficiles à lire pour les humains et les ordinateurs.
Les algorithmes OCR sont constamment améliorés et les ordinateurs sauront mieux résoudre les CAPTCHAs que les humains. 

Les CAPTCHA basés sur les mathématiques sont assez normés pour que les spambots automatisés puissent trouver comment les valider.

Un CAPTCHA basé sur des questions n'est pas vulnérable à OCR.
Les humains peuvent toujours être payés pour trouver les réponses.
Selon Wikipedia, des entreprises payent environ 0,80$ à 1,20$ pour 1000 captcha résolus à des solveurs humains au Bangladesh, en Chine, en Inde et de nombreux autres pays en développement.
Pour cette raison, un captcha devrait être combiné avec d'autres mécanismes.

Un captcha peut bloquer les utilisateurs aveugles, malvoyants, sourds. Le captcha n'est donc pas une solution complète.
Il est bienvenue de considérer les implications d'un système qui empêche certains utilisateurs handicapés de participer avec la communauté.
Il est important d'envisager une alternative sérieuse pour permettre à tous les utilisateurs de créer un compte pour pouvoir contribuer sur le wiki. (C'est une exigence légale dans certaines juridictions.)

ConfirmEdit

Cette extension est installée sur MediaWiki depuis la version 1.18 et plus.

L'extension ConfirmEdit empêche les utilisateurs non-enregistrés de publier directement des liens avec un captcha basique affiché par défaut quand un utilisateur non-enregistré tente d'ajouter un lien.

Le captcha peut être déclenché sur un certain nombre d'événements. Exemple :

Enregistrement de l'utilisateur 
Modifications ajoutant de nouveaux liens externes non reconnus
Toutes les modifications

L'extension est livrée avec un test par défaut qui n'est pas destiné à une utilisation en production.

Les Administrateurs de Mediawiki qui installent ConfirmEdit sur un wiki public sont invités à utiliser l'un des modules captcha contenus dans l'extension. Il y en a cinq au total.

Manuel Mediawiki pour ConfirmEdit : https://www.mediawiki.org/wiki/Extension:ConfirmEdit

Extension QuestyCaptcha

Un captcha robuste aujourd'hui intègre des questions personnalisées.

QuestyCaptcha permet aux utilisateurs de répondre à une question plutôt que d'utiliser un problème mathématique facilement détourné, ou, une image.

Cette extension semble être présente par défaut sur Mediawiki 1.28.0 dans le dossier de l'extension ConfirmEdit.

Si nécessaire, télécharger QuestyCaptcha présent dans le paquet ConfirmEdit : https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/archive/master.tar.gz

Le gestionnaire du site ajoute des questions réponses dans le fichier de configuration LocalSettings.php pour un affichage aléatoire de différentes questions.

Éditer le fichier LocalSettings.php à la racine de votre installation MediaWiki et ajouter la ligne suivante.

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ) );

Ajouter ensuite les questions.

$wgCaptchaQuestions = array(
'Merci de réécrire ce mot, "GreeN", ici :' => 'GreeN',
'Saisir ce code 01001, ici :' => '01001',
'Combien de doigts sur une main ?' => array (5,'cinq'),
'Quel est cet animal ? <img src="https://napoleon-storage.s3.eu-west-3.amazonaws.com/product-images/main/canifrisbee-frisbee-easy-glider-en-mousse-technologique-pour-chien-5cdd1a2f07589.jpeg" alt="" title="" /> Votre réponse, ici :' => array('chien','dog'),
);

Pour ajouter plusieurs réponses, utiliser un tableau.

$arr = array(
"Quelle est une des couleur sur cette page Web?" => array('beige','gris','bleu','blanc','noir','white','black')
);

Si nécessaire configurer les déclencheurs de ConfirmEdit. Vous pouvez écrire "true" pour que cela se produise et "false" pour que cela ne se produise pas.

$WgMainCacheType = CACHE_ANYTHING ;
$WgCaptchaTriggers [ 'edit' ] = true ;
$WgCaptchaTriggers [ 'create' ] = true ;
$WgCaptchaTriggers [ 'createtalk' ] = true ;
$WgCaptchaTriggers [ 'addurl' ] = true ;
$WgCaptchaTriggers [ 'createaccount' ] = true ;
$WgCaptchaTriggers [ 'badlogin' ] = true ;

Complément : https://www.mediawiki.org/wiki/Extension:ConfirmEdit#QuestyCaptcha

Faiblesses QuestyCaptcha n'est pas conçu pour repousser les attaques de vandales déterminés.

QuestyCaptcha pourrait ne pas être le meilleur captcha pour vous contre des spammers qui peuvent simplement résoudre les captchas et les charger dans un vandalbot.

Source Mediawiki : https://www.mediawiki.org/wiki/Extension:QuestyCaptcha

Le captcha QuestyCaptcha a été installé et est fonctionnel.

Extension QuestyPage

Permet à QuestyCaptcha d'obtenir ses données à partir d'une page wiki.

Source Mediawiki : https://www.mediawiki.org/wiki/Extension:QuestyPage

Extension Google ReCaptcha (NoCaptcha)

Le module ReCaptcha (NoCaptcha) a été introduit dans la version MediaWiki 1.26 et permet de renforcer la sécurité suite à l'édition d'une page Mediawiki.

Ajouter dans le fichier LocalSettings.php :

soit :
$wgReCaptchaKey = 'your-recaptcha-key';
$wgReCaptchaSecret = 'your-recaptcha-secret';

soit :
wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';
$wgReCaptchaSiteKey = 'your public/site key here';
$wgReCaptchaSecretKey = 'your private key here';

Site officiel de Google Recaptcha (NoCaptcha) : https://www.google.com/recaptcha/intro/v3.html
Page officielle sur Mediawiki : https://www.mediawiki.org/wiki/Extension:ReCaptcha

Captcha KeyCAPTCHA

Page officielle sur Mediawiki : https://www.mediawiki.org/wiki/Extension:KeyCAPTCHA
Site officiel : https://www.keycaptcha.com

Captcha Asirra

Le captcha Asirra demande à l'utilisateur de distinguer les chats et les chiens.

Particulièrement intrusif pour les utilisateurs, cette solution peut s'avérer efficace.

Extensions complémentaires pour réduire le spam

L'idée première d'un wiki est de permettre à tous de modifier les pages.

Il existe de nombreuses extensions qui permettent de protéger un wiki malgré les abus des spammeurs.

Lorsque de nombreuses vérifications sont effectuées les robots peuvent facilement surcharger votre wiki. Vérifier le coût des ressources des protections.

Filtre Abuse

L'extension AbuseFilter permet aux utilisateurs privilégiés de positionner des contrôles spécifiques sur les actions des utilisateurs.

Les modifications qui correspondent à certains critères sont filtrées pour empêcher les utilisateurs d'ajouter des liens externes ou pour bloquer un utilisateur qui supprime par exemple plus de 2000 caractères.

Source du manuel : https://www.mediawiki.org/wiki/Extension:AbuseFilter/fr

Source des exemples : https://www.mediawiki.org/wiki/Manual:Combating_spam/AbuseFilter_examples

Force Preview

Cette extension oblige les utilisateurs non-enregistrés à prévisualiser avant de sauvegarder. C'est une sorte de garde-fou qui a un effet dissuasif. Pas de configuration nécessaire.
https://www.mediawiki.org/wiki/Extension:ForcePreview

Title Blacklist pour interdire les titres et utilisateurs incohérents

Cette extension est inclue dans Mediawiki depuis la version 1.21 et plus.
Cette extension interdit la création de page ou de noms d'utilisateurs avec des titres sans aucun sens (type : ééééé) ou injurieux. Vous pouvez définir votre propre liste noire, ou utiliser celle de Mediawiki, ou les deux.
Manuel : https://www.mediawiki.org/wiki/Extension:Title_Blacklist

Spam Blacklist

L'extension SpamBlacklist est intégrée à partir de la version 1.21 et plus de Mediawiki.
Cette extension bloque l'édition d'une page quand un utilisateur tente de publier un lien interdit. Les liens interdits sont sur une liste noire.
Vous pouvez utiliser votre propre liste noire pour interdire des liens.

Activer cette extension :
wfLoadExtension ( 'SpamBlacklist');

Lien du manuel mediawiki : https://www.mediawiki.org/wiki/Extension:SpamBlacklist

Spam Blacklist - Liste noire

La liste noire de Wikimedia contient des liens de sites qui ont été reconnus indésirables et qui sont susceptibles de vous spammer.
Vous pourriez avoir besoin d'autoriser un des liens blacklistés. Aller sur la page MediaWiki:Spam-whitelist et ajouter le lien à autoriser.
Les pages locales MediaWiki:Spam-blacklist, MediaWiki:Spam-whitelist, MediaWiki:Email-blacklist et MediaWiki:Email-whitelist sont utilisées même en cas d'ajouts de sources supplémentaires.
Télécharger la source pour Spam-blacklist : https://meta.wikimedia.org/wiki/Spam_blacklist
Utiliser cette liste sera suffisant pour bloquer la plupart des tentatives de spam.

Spam Blacklist ou wgSpamBlacklistFiles

Activer la liste noire de mediawiki depuis le fichier LocalSettings.php :

require_once( "$IP/extensions/SpamBlacklist/SpamBlacklist.php" );
$wgSpamBlacklistFiles = array(
  "http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw&sb_ver=1", // Wikimedia's list
  //  database      title
  "DB: wikidb MediaWiki:Spam-blacklist",
);

Spam Blacklist - Modifier la Blacklist avec SBHandler

Source : https://meta.wikimedia.org/wiki/User:Erwin/SBHandler

AntiBot

Bloque les robots spammeurs.
L'objectif est de permettre le développement privé et la collaboration limitée sur les filtres pour les outils de spam courants tels que XRumer.
Manuel Mediawiki pour l'extension AntiBot : https://www.mediawiki.org/wiki/Extension:AntiBot
(N'est pas installée.)

RudeProxyBlock

Bloque les adresses d'une liste donnée. Cette extension fonctionne, mais il faut créer soi-même la liste et celle qui est fournie n'est pas mise à jour.

https://www.mediawiki.org/wiki/Extension:RudeProxyBlock

(N'est pas installée.)

SimpleAntiSpam

It was merged into the core MediaWiki software as of version 1.22.0.

require_once "$IP/extensions/SimpleAntiSpam/SimpleAntiSpam.php";

Aller sur la page Special:Version de votre wiki pour vérifier que l'extension est installée avec succès.

https://www.mediawiki.org/wiki/Extension:SimpleAntiSpam

(N'est pas utilisée.)

Limiter les publications avec wgRateLimits

Options simples pour limiter le débit de publications pour freiner les inondations de spams.

Source : https://www.mediawiki.org/wiki/Manual:%24wgRateLimits

TorBlock

Bloque les internautes qui tentent de se connecter de manière anonyme à votre site, par l'utilisation d'un réseau Tor.

Source : https://www.mediawiki.org/wiki/Extension:TorBlock

(N'est pas installé.)

Bloquer les robots spammeurs avec wgProxyList

Le site http://www.stopforumspam.com propose une liste de plusieurs dizaines de milliers d'adresses de robots spammeurs que vous pouvez télécharger et utiliser pour leur bloquer l'accès à votre site.

Avec GNU/Linux vous pouvez créer automatiquement un fichier bannedips.php que vous pourrez mettre à jour régulièrement avec le script ci-dessous.
Copier le script suivant dans un traitement de texte et sauvegardez-le sous le nom updateBannedIPs.sh.
Il doit être ensuite rendu exécutable (Clic droit > propriétés > permissions > exécution).

#!/bin/bash
# This script is using data from http://www.stopforumspam.com/downloads/
# Updated once per day, limited to 3 downloads per IP per day$
# Usage:
# 1# run this script
# 2# Copy bannedips.php in your /extensions directory
# 3# Be sure to have the line:
#      require_once("$IP/extensions/bannedips.php");
#    in your LocalSettings.php
# Infos: http://fr.wikibooks.org/wiki/MediaWiki_pour_d%C3%A9butants/S%C3%A9curiser_son_Wiki#Bloquer_les_robots_spammeurs
wget "http://www.stopforumspam.com/downloads/bannedips.zip" -O bannedips.zip
unzip bannedips.zip
echo "<?php" > bannedips.php;
echo \$"wgProxyList = array(" >> bannedips.php; echo -n "'" >> bannedips.php;
cat bannedips.csv | awk 'gsub (",","\x27,\n\x27")' >> bannedips.php;
echo "');" >> bannedips.php;
rm bannedips.csv;
rm bannedips.zip;

Si le awk de votre distribution sort avec un défaut Segmentation, vous pouvez remplacer awk par sed.

#! / Bin / bash
Wget http://www.stopforumspam.com/downloads/bannedips.zip
Unzip -u bannedips.zip
echo "<? php"> bannedips.php
echo \ $ "wgProxyList = array (" >> bannedips.php; echo " '" >> bannedips.php -n
cat bannedips.csv |  sed -e 's /,/\x27\n\x27/g' >> bannedips.php
echo " ');"  >> bannedips.php
Rm bannedips.csv
Rm bannedips.zip *

Dans un terminal, placez-vous dans le dossier où se trouve le script choisi, le premier script utilisant awk suffira si il fonctionne correctement puis lancer la commande suivante :

sh updateBannedIPs.sh

Le résultat apparaît dans le même dossier. Le fichier bannedips.php a été créé.

Un script alternatif totalement en PHP existe. Site : http://www.pschmidt.it/vim_source/updateBanned_php.txt Le code du script PHP
Copier bannedips.php dans le dossier /extensions de votre wiki.

Dans le fichier LocalSettings.php ajouter la ligne suivante : require_once("$IP/extensions/bannedips.php");

Il n'est pas nécessaire de charger $wgProxyList déjà présente dans le fichier bannedips.php
Cette extension a été installée mais n'apparaît pas dans Pages Spéciales : Version.

Vous venez d'interdire cent quarante mille spammeurs.

Compléter la liste des ip interdites

A tester avec la base suivante, à ajouter. Voir si le format correspond.
https://myip.ms/files/blacklist/general/latest_blacklist.txt

Lenteur depuis mediawiki 1.30

L'extension banneips fait boguer la page de connexion depuis la version de mediawiki 1.30 stable qui affiche une page blanche.
Pour corriger ce problème le tableau des ips doit être convertit en tableau indexé.

La documentation de mediawiki 1.30 dit que l'utilisation d'un tableau associatif pour $ wgProxyList, où l'adresse IP est dans la clé au lieu de la valeur, est déconseillée (par exemple ['127.0.0.1' => 'valeur']). Veuillez convertir ces tableaux en tableaux indexés / séquentiels (par exemple ['127.0.0.1']).

#Appeler le script depuis LocalSettings.php
require_once("$IP/extensions/bannedips.php");

#Remplacer l'ancien script extensions/bannedips.php
<?php
$wgProxyList = array(
'1.0.135.30',
'1.0.137.139',
'1.0.178.169',
'1.0.178.218',
'1.0.178.58',
);

par

<?php
$wgProxyList = array(
['1.0.135.30'],
['1.0.137.139'],
['1.0.178.169'],
['1.0.178.218'],
['1.0.178.58']
);

Le problème est que cette nouvelle méthode est extrêmement gourmande en ressource.
Réduire ce script, surtout si le wiki n'est pas la cible d'attaques particulières.
Il n'est plus possible d'utiliser le script proposé par défaut.
Le temps de connexion prend de longues secondes.

Semblait avoir été résolu mais la nouvelle méthode est très lente, et, depuis un autre wiki, le warning suivant est affiché :
Warning: IPSet: Bad mask '' from 'Array', ignored in /homepages/38/d548381562/htdocs/CLPublic/wiki/vendor/wikimedia/ip-set/src/IPSet.php on line 125

J'ai supprimé l'extension pour le moment.

Mon retour sur la page officielle de $wgProxyList : https://www.mediawiki.org/wiki/Manual_talk:$wgProxyList#White_page_with_mediawiki_1.30
Complément sur le bogue traqueur de phabricator : https://phabricator.wikimedia.org/T182841

Antispam natif $wgSpamRegex

Cette fonction se configure dans le fichier LocalSettings.php et utilise des expressions régulières.

Les expressions régulières sont des suites de caractères qui permettent de définir de manière économique un ensemble d'expressions.

Au lieu de faire la liste de toutes les pages d'un domaine à bannir, une expression régulière permet de résumer toutes ces pages.

Le site MediaWiki fournit l'exemple suivant qui interdit l'ajout de liens contenant des mots très fréquents dans les spams et qui empêche aussi l'ajout de contenu caché :

$wgSpamRegex = "/".                        # The "/" is the opening wrapper
              "s-e-x|zoofilia|sexyongpin|grusskarte|geburtstagskarten|animalsex|".
              "sex-with|dogsex|adultchat|adultlive|camsex|sexcam|livesex|sexchat|".
              "chatsex|onlinesex|adultporn|adultvideo|adultweb.|hardcoresex|hardcoreporn|".
              "teenporn|xxxporn|lesbiansex|livegirl|livenude|livesex|livevideo|camgirl|".
              "spycam|voyeursex|casino-online|online-casino|kontaktlinsen|cheapest-phone|".
              "laser-eye|eye-laser|fuelcellmarket|lasikclinic|cragrats|parishilton|".
              "paris-hilton|paris-tape|2large|fuel-dispenser|fueling-dispenser|huojia|".
              "jinxinghj|telematicsone|telematiksone|a-mortgage|diamondabrasives|".
              "reuterbrook|sex-plugin|sex-zone|lazy-stars|eblja|liuhecai|".
              "buy-viagra|-cialis|-levitra|boy-and-girl-kissing|". # These match spammy words
              "dirare\.com|".           # This matches dirare.com a spammer's domain name
              "overflow\s*:\s*auto|".   # This matches against overflow:auto (regardless of whitespace on either side of the colon)
              "height\s*:\s*[0-4]px|".  # This matches against height:0px (most CSS hidden spam) (regardless of whitespace on either side of the colon)
              "\<\s*a\s*href|".         # This blocks all href links entirely, forcing wiki syntax
              "display\s*:\s*none".     # This matches against display:none (regardless of whitespace on either side of the colon)
              "/i";                     # The "/" ends the regular expression and the "i" switch which follows makes the test case-insensitive
                                        # The "\s" matches whitespace
                                        # The "*" is a repeater (zero or more times)
                                        # The "\s*" means to look for 0 or more amount of whitespace

Second exemple :

$wgSpamRegex = "/online-casino|buy-viagra|adipex|phentermine|adult-website\.com|display:none|overflow:\s*auto;\s*height:\s*[0-4]px; / i ";

Empêche toute mention de «casino en ligne» ou «buy-viagra» ou «adipex» ou «phentermine».

Le '/ i' à la fin rend la case de recherche insensible.

Il bloque également les modifications qui tentent d'ajouter des éléments cachés ou débordants, astuce commune utilisée dans beaucoup d'attaques de masse pour tenter de cacher le spam.

Pour une efficacité maximale, il doit être combiné avec un http: BL API Key que vous pouvez obtenir en vous inscrivant pour le Projet Honey Pot, un projet de suivi des spams distribués.

Bad Behavior - Mauvais comportement

Bad Behavior est une première ligne de défense qui bloque toutes les demandes des spammeurs.
Utiliser une seconde ligne de défense complémentaire en utilisant un anti-spam traditionnel.
Bad Behavior rejette totalement les robots de spam en envoyant un code d'erreur 4xx approprié.
Au lieu de regarder le spam, nous regardons le spammeur. Bad Behavior analyse les en-têtes HTTP, l'adresse IP et les autres métadonnées concernant la requête afin de déterminer si elle est spam ou malveillante.
Bad Behavior détermine si la requête correspond à un profil d'activité malveillante ou polluante connue. Si oui, la demande est bloquée.
Bad Behavior ajoute un cookie qui peut être désactivé.
Bad Behavior est disponible en tant qu'extension MediaWiki : http://bad-behavior.ioerror.us/support/installation/mediawiki/
Quelques problèmes connu en cas d'utilisation du cache.

Modérer la publication avec Moderation

C'est l'une des méthodes de protection anti-vandale les plus efficaces et ayant peu d'impact sur les utilisateurs légitimes.

Chaque modification (ou transfert d'image) par un nouvel utilisateur est envoyée à la modération.

Jusqu'à ce que le modérateur approuve cette modification, la page est inchangée. L'édition en attente n'est ni dans l'historique de la page ni dans les modifications récentes.

L'utilisateur peut voir son montage et continuer à éditer sa propre version de la page.

Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:Moderation

Bloquer une plage d'adresses IP avec GlobalBlocking

L'extension GlobalBlocking permet à un utilisateur avec les autorisations appropriées de bloquer une plage d'adresses IP ou une adresse IP (mais pas de comptes utilisateur).
Il est destiné à être utilisé pour lutter contre le vandalisme cross-wiki sévère et le spam.
Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:GlobalBlocking

Gestion du contenu révisé avec FlaggedRevs

Source : https://www.mediawiki.org/wiki/Extension:FlaggedRevs
Source : https://www.mediawiki.org/wiki/Extension:Approved_Revs

Limiter la modification de l'espace de noms principal avec wgNamespaceProtection

Depuis Mediawiki 1.14, l'espace de noms MediaWiki: est protégé des utilisateurs avec le droit 'editinterface'.
Il est défini dans Setup.php et ne peut être modifié dans LocalSettings.php pour des raisons de sécurité.

Limiter l'édition dans l'espace de noms principal aux personnes d'un groupe qui possèdent l'autorisation edit-main.
Accorder le droit 'editinterface' aux groupes autres que sysops pouvant modifier MediaWiki: namespace.

Il n'est pas possible de restreindre l'accès en lecture à un espace de noms avec $wgNamespaceProtection.

$wgNamespaceProtection[NS_MAIN]      = array( 'edit-main' );

Manuel Mediawiki : https://www.mediawiki.org/wiki/Manual:%24wgNamespaceProtection

Cacher des modifications récentes avec Recent_Changes_Cleanup

Avec cette extension, vous pouvez garder votre page RC aussi propre que vous le souhaitez.
N'oubliez pas que la ligne est uniquement cachée dans la vue RC par défaut.
La ligne cachée peut toujours être vu par un utilisateur si il clique sur "show bots".

Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:Recent_Changes_Cleanup

Utiliser des protections DNS

DNS blacklists

List of DNS blacklists to use, if $wgEnableDnsBlacklist is true. This replaces $wgSorbsUrl.

Array values can either be a string containing the URL of the DNS blacklist, or an array containing the URL of the blacklist and an associated "key" should the blacklist require one.

You should end the domain name with a "." to avoid searching your eventual domain search suffixes.

Dans LocalSettings.php ajouter le code suivant.
$wgDnsBlacklistUrls = array('http.dnsbl.sorbs.net.', # String containing URL
array( 'dnsbl.httpbl.net.', 'mykey' ), # Array with URL and key, for services that require a key
array( 'opm.tornevall.org.' )  # Array with just URL. While this works, it is recommended that you just use a string as shown above
);

Ce code n'a pas été intégré, faire une recherche sur la clé à utiliser.
$wgEnableDnsBlacklist = true;
$wgDnsBlacklistUrls = array( 'xbl.spamhaus.org', 'dnsbl.tornevall.org', 'web.dnsbl.sorbs.net' );

Source : https://www.mediawiki.org/wiki/Manual:Combating_spam/en#DNSBL

DNSBL

Vous pouvez configurer MediaWiki pour vérifier chaque adresse IP d'édition sur un ou plusieurs DNSBL (listes noires basées sur DNS) qui ne nécessite aucun entretien mais augmente légèrement la latence d'édition.

Par exemple, vous pouvez ajouter cette ligne à LocalSettings.php pour bloquer de nombreux proxys ouverts et spammeurs de forum connus.

$wgEnableDnsBlacklist = true;
$wgDnsBlacklistUrls = array ('xbl.spamhaus.org', 'dnsbl.tornevall.org', 'http.dnsbl.sorbs.net');

(Ce code n'a pas été intégré)

Sorbs

Bien que le SORBS d'origine était principalement destiné à traiter les proxies Web ouverts et le courrier indésirable, il existe d'autres listes spécifiques au spam Web qui peuvent donc être plus appropriées.

opm.tornevall.org

.opm.tornevall.org
Fonctionne de manière très similaire à SORBS DNSBL, mais cible les proxies ouverts et les spams de formulaire Web. Une grande partie de son contenu est consolidée à partir d'autres listes  existantes et IP abusives.

https://dnsbl.tornevall.org

dnsbl.httpbl.org

.dnsbl.httpbl.org.
Spécifiquement cibles bots qui récoltent les adresses e-mail à partir de pages Web pour les listes de courrier en vrac, laisser un commentaire spam ou tenter de voler des mots de passe à l'aide d'attaques de dictionnaire. Il nécessite l'enregistrement de l'utilisateur avec projecthoneypot.org pour une clé API de 12 caractères. Si cette clé (par exemple) était 'myapitestkey', une recherche qui ressemblerait autrement '89 .67.45.123.http.dnsbl.sorbs.net. ' Ou '89 .67.45.123.opm.tornevall.org. Devrait être 'myapitestkey.89.67.45.123.dnsbl.httpbl.org.

Liens complémentaires sur DNSBL

https://www.spamhaus.org/xbl

https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists

En général, l'alimentation de l'adresse de tout robot ou proxy ouvert dans un moteur de recherche renverra de nombreuses listes sur lesquelles ces IP abusives ont déjà été signalées. Dans certains cas, les listes feront partie de sites anti-spam, dans d'autres un site préconisant l'utilisation de proxies ouverts ne sera pas seulement la liste proxy qui a été abusé pour le spam de votre installation wiki, mais des centaines d'autres proxies comme lui qui sont Également ouvert pour abus.

P R O X Y

Alors que toutes les listes en texte brut de proxies ouverts doivent toujours être importés dans votre wiki manuellement, un Spambot outil de recherche peut être configuré comme un script automatisé pour interroger l'une des bases de données suivantes:

   FSpamlist - fspamlist.com
   StopForumSpam - stopforumspam.com
   Sorbs - sorbs.net
   Spamhaus - spamhaus.org
   SpamCop - spamcop.net
   ProjectHoneyPot - projecthoneypot.org
   Bot Scout - botscout.com
   DroneBL - dronebl.org
   AHBL - ahbl.org
   S5h spam - all.s5h.net

Project Honey Pot

Site officiel : projecthoneypot.org

Certains sites anti-spam, comme projecthoneypot.org, fournissent le code que vous êtes invité à inclure dans vos propres pages Web. En règle générale, les pages contiennent une ou plusieurs adresses de courriel uniques, aléatoires et cachées ou des liens, destinés non pas à vos visiteurs humains, mais pour les spambots.  Chaque fois que la page est diffusée, les adresses intégrées sont automatiquement modifiées, ce qui permet aux pièces individuelles de spam d'être directement et définitivement adaptées à l'adresse IP des robots qui ont récolté les adresses de vos sites.  L'adresse IP que le bot utilisé pour afficher votre site est automatiquement soumise aux opérateurs du service de liste noire.  Souvent, un lien vers un «commentaire» ou un «livre d'or» faux est également caché comme un piège aux bots qui affichent des spams aux formulaires Web.  Voir Honeypot (calcul) .

Une fois que l'adresse du spammeur est connue, elle est ajoutée aux listes noires (voir ci-dessus) afin que vous et d'autres puissiez à l'avenir avoir un visiteur robotique non désiré sur vos sites.

Bien que les scripts de honeypot et les serveurs de liste noire puissent automatiser une grande partie de la tâche d'identification et de traitement des adresses IP spambot, la plupart des sites de liste noire fournissent des liens vers des pages Web sur lesquelles on peut manuellement rechercher des informations sur une adresse IP ou signaler une IP abusive comme spambot. Il peut être conseillé d'inclure certains de ces liens sur les pages spéciales de votre wiki pour la commodité des administrateurs de votre site.

Ne pas afficher les logs de suppression avec wgLogRestrictions

Manuel : https://www.mediawiki.org/wiki/Manual:$wgLogRestrictions

Limiter l'accès aux journaux à ceux qui ont un certain droit.
Les utilisateurs sans cela ne les verront pas dans le menu d'options et ne pourront pas les voir.
Les journaux restreints ne seront plus ajoutés aux dernières modifications.
Pour supprimer les anciens, voir à utiliser Rebuildrecentchanges.php

# Exemple pour la saisie : wgLogRestrictions["log's name"] = 'permission to access';
# Ne pas afficher les logs de suppressions :
# $wgLogRestrictions = ['suppress' => 'suppressionlog'];

# Ne pas afficher les logs de UserMerge.
$wgLogRestrictions = ['usermerge' => 'bureaucrat'];

# Bogue 1
# Fonctionne en partie depuis Spécial:Journal
# Les logs ne sont pas affichés.
# Les logs ne sont pas affichés non plus avec mon utilisateur bureaucrate connecté.

# Bogue 2
# Erreur depuis la page Spécial:Journal/usermerge
Vous ne pouvez pas ⧼action-bureaucrat⧽, pour la raison suivante :
Vous n’avez pas les droits suffisants pour réaliser l’action demandée.

Filtrage par agent utilisateur

Lorsque vous bloquez un spammeur sur votre wiki, recherchez le journal d'accès de votre site par IP pour déterminer quelle chaîne d'agent utilisateur a fourni. Par exemple:
grep ^195.230.18.188 /var/log/apache2/access.log 

L'emplacement du journal d' accès pour votre hôte virtuel est généralement définie en utilisant la CustomLog directive. Une fois que vous avez trouvé les accès, vous verrez quelques lignes comme ceci:
195.230.18.188 - - [16/Apr/2012:16:50:44 +0000] "POST /index.php?title=FlemmingCoakley601&action=submit HTTP/1.1" 200 24093 "-" "" 

L'agent utilisateur est la dernière chaîne entre guillemets sur la ligne, dans ce cas une chaîne vide. Certains spammeurs utiliseront des chaînes d'agent utilisateur utilisées par les navigateurs réels, tandis que d'autres utiliseront des chaînes d'agents utilisateur mal formées ou vierges. Si elles sont dans cette dernière catégorie, vous pouvez les bloquer en ajoutant ceci à votre fichier .htaccess :

SetEnvIf User-Agent ^regular expression matching user agent string goes here$ spammer=yes
Order allow,deny
allow from all
deny from env=spammer

Cela renverra une erreur interdite 403 à toute connexion IP avec un agent utilisateur correspondant à l'expression régulière spécifiée. Prenez soin d'échapper à tous les caractères regexp nécessaires dans la chaîne de l'agent utilisateur tels que. () - avec des barres obliques inverses (\). Pour faire correspondre les agents utilisateurs vides, il suffit d'utiliser "^ $".

Même si la chaîne d'agent utilisateur du spammeur est utilisée par les navigateurs réels, si elle est ancienne ou rarement rencontrée, vous pouvez utiliser les règles de réécriture pour rediriger les utilisateurs vers une page d'erreur en leur conseillant de mettre à niveau leur navigateur:

RewriteCond %{HTTP_USER_AGENT} "Mozilla/5\.0 \(Windows; U; Windows NT 5\.1; en\-US; rv:1\.9\.0\.14\) Gecko/2009082707 Firefox/3\.0\.14 \(\.NET CLR 3\.5\.30729\)"
RewriteCond %{REQUEST_URI} !^/forbidden/pleaseupgrade.html
RewriteRule ^(.*)$ /forbidden/pleaseupgrade.html [L]

Preventing blocked spammers from consuming resources

A persistent spammer or one with a broken script may continue to try to spam your wiki after they have been blocked, needlessly consuming resources. By adding a deny from pragma such as the following to your .htaccess file, you can prevent them from loading pages at all, returning a 403 Forbidden error instead:

Order allow,deny
allow from all
deny from 195.230.18.188

Nettoyer les spams sur mediawiki

Si le flux de spam diminue, ça ne nettoiera pas la base de données.
Utiliser des extensions ou des scripts de nettoyage pour supprimer massivement les messages inutiles et conserver une base de données avec des données cohérentes et optimisées.

Nettoyer Manuellement

Consulter les pages spéciales / pages orphelines. Lier les pages à conserver si possible, si nécessaire.
Identifier et supprimer les pages inutiles.

Nettoyer Automatiquement

Par précaution, faites quand même une sauvegarde de votre base avant.

Afficher, lier, supprimer les pages orphelines

Afficher les pages orphelines pour les lier ou les supprimer depuis la page spéciale : Spécial:Pages_orphelines.

Supprimer des pages en masse pour un utilisateur avec l'extension Nuke

Cette extension vient avec MediaWiki 1.18 et plus. Vous n'avez donc pas à le télécharger de nouveau.
L'extension Nuke permet aux sysops de supprimer des pages en masse.

L'intérêt est de pouvoir identifier un utilisateur spammeur et l'ensemble des spams en une seule fois.
Ici, ce sont toutes les pages d'un spammeur qui peuvent être supprimées en une seule fois.

Utiliser l'extension Nuke ne permet pas de supprimer des utilisateurs en masse.
Utiliser l'extension Nuke ne permet pas de supprimer les historiques en masse.

Ajoutez le code suivant au bas de votre LocalSettings.php pour activer l'extension Nuke.

WfLoadExtension ( 'Nuke' );

Accédez à Pages spéciales pour vérifier que l'extension est correctement installée.

Allez à Pages spéciales : Nuke afin de supprimer en masse des pages récemment ajoutées par un utilisateur ou une adresse IP. La page spéciale est répertoriée dans Special: SpecialPages comme Mass delete .

Vous pouvez également spécifier un motif pour le titre de la page. Le champ accepte les caractères génériques SQL, comme %lol% .

Un journal de toutes les suppressions est conservé à Special: Log / delete.

Cette extension est activée et permet la suppression de pages en masse.

Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:Nuke

Configurer l'extension Nuke

L'utilisateur droit "nuke" est automatiquement accordé au groupe d'utilisateurs "sysop".

Pour le découpler et affecter ce droit à un nouveau groupe d'utilisateurs dédié tel que "Nuke", ajoutez ce qui suit à votre fichier "LocalSettings.php".
$ WgGroupPermissions [ 'sysop' ] [ 'nuke' ] = false ;
$ WgGroupPermissions [ 'nuke' ] [ 'nuke' ] = true ;

Cleanmediawiki

Cleanmediawiki se base sur l'ID utilisateur pour supprimer tous les ID de compte utilisateur spécifiés et leurs pages, révisions, modifications, index et cache associés.

Sur Github : https://github.com/liruqi/cleanmediawiki
Fork : https://github.com/ZerooCool/cleanmediawiki

Identifier les comptes spammeurs depuis PHPMyAdmin, par exemple, un bloc de 500 utilisateurs de comptes de spam allant de l'ID utilisateur 12021 à 12521.

Lancer la commande, fonctionne rapidement.
./cleanmediawiki.sh wikidatabasename 12021 12521

Attention :
Certaines pages, y compris «Main_page», peuvent afficher un message du type «La révision n ° 1895 de la page intitulée« Main_page »n'existe pas.» 
Même si je pouvais constater qu'il y avait eu de nombreuses révisions dans l'historique des révisions, wiki était obstiné en voulant obtenir cette révision perdue.
Les révisions ont probablement été supprimée après qu'un utilisateur de spam eu modifié la page et qu'il ait été supprimé.

Le code findAnomalies.php permet d'afficher toutes les pages qui manquent dans les révisions avec la commande :
php findAnomalies.php --mode=plmra
Le dérivé –fix ne fonctionne pas (Probablement qu'il n'a jamais été codé et a simplement été mentionné comme une idée).

Heureusement, attachLatest.php a fonctionné! Tout ce que je devais faire était :
php maintenance/attachLatest.php --regenerate-all --fix
Il parcourut toutes les pages et fixa la dernière révision en fonction des horodatages.
Le résultat est comme si tout le spam avait disparu avec tout le contenu authentique intact!

 Source : https://asd.learnlearn.in/mediawiki-spam-cleanup/
You can send me an email too to akshay@learnlearn.in or akshay@autistici.org. If you are okay with using google services I also have a gmail - asdofindia@gmail.com.
mozillians.org/u/asdofindia
github.com/asdofindia
gitlab.com/asdofindia
asdofindia@joindiaspora.com
@akshay@mastodon.technology
twitter.com/asdofindia
plus.google.com/+AkshaySDinesh

Clean up MediaWiki after a spammer

The simplest answer to this is to restore a backup of the database.  If however you don't have one then this is how to clean up the database.
The core of the database resides in four tables - user, revision, page and text.  Revision can be considered the core of the core, as the others link through it to relate to one another.
Users create revisions which have a page and text associated with them.
To find all of the pages and revisions created by a user, you can use the following SQL commands:

select user_id from user where user_email='a@b.com';

This will give you the internal user_id number referenced in the revision, page and text tables to allow you to remove what that user added.
First remove the text:

delete from text where old_id in (select rev_text_id from revision where rev_user=user_id);

Where user_id is the one you got from the select statement above.
Then remove the pages:

delete from page where page_id in (select rev_page from revision where rev_user=user_id);

Now remove the revisions:

delete from revision where rev_user=user_id;

And finally remove the user themselves:

delete from user where user_id=user_id;

Source : http://www.lairdscomputer.com/Blog/tabid/62/EntryId/27/How-to-clean-up-MediaWiki-after-a-spammer.aspx

Merger ou supprimer un utilisateur avec l'extension UserMerge

Permet de fusionner un utilisateur A avec aucun contenu vers un utilisateur B avec contenu, et, de supprimer l'utilisateur A. (Le pseudo et le contenu de l'utilisateur B sont préservés.)
UserMerge est lent à utiliser car chaque merge doit être effectué manuellement.

Manuel en anglais : https://www.mediawiki.org/wiki/Extension:UserMerge
Manuel en français : https://www.mediawiki.org/wiki/Extension:UserMerge/fr
Page de téléchargement : https://www.mediawiki.org/wiki/Special:ExtensionDistributor/UserMerge
Télécharger le fichier : https://extdist.wmflabs.org/dist/extensions/UserMerge-REL1_32-66c7030.tar.gz

# Installation en ligne de commande :
cd /var/www/wiki.visionduweb.fr/extensions
sudo wget https://extdist.wmflabs.org/dist/extensions/UserMerge-REL1_32-66c7030.tar.gz
sudo tar -xzf UserMerge-REL1_32-66c7030.tar.gz
sudo chown -R www-data:www-data UserMerge
sudo rm UserMerge-REL1_32-66c7030.tar.gz

# Activer l'extension en ajoutant le code suivant à la fin du fichier LocalSettings.php
wfLoadExtension( 'UserMerge' );
# Par défaut, personne ne peut utiliser cette fonction, permise uniquement au bureaucrate.
$wgGroupPermissions['bureaucrat']['usermerge'] = true;
# Les utilisateurs non fusionnables peuvent être définis (exemples) :
# Autoriser la fusion de tous les utilisateurs (par défaut, le groupe 'sysop' est non fusionnable)
# $wgUserMergeProtectedGroups = array();
# Interdire la fusion des utilisateurs dans les groupes 'sysop' ou 'awesomeusers'
# $wgUserMergeProtectedGroups = array( 'sysop', 'awesomeusers' );

Utiliser l'extension :
Une nouvelle page spéciale Special:UserMerge avec le titre "Fusionner et supprimer des utilisateurs" est créée.
Vous ne pouvez pas supprimer un utilisateur A sans avoir fusionné l'utilisateur A à B
Vous ne pouvez pas fusionner votre propre compte (utilisateur connecté) dans un autre utilisateur
Si vous omettez le champ Nouvel utilisateur, l'extension remplit automatiquement le nouvel utilisateur en tant que Anonyme (id_utilisateur 0), et vous demande de confirmer une fusion avec Anonyme.
Ceci est utilisé pour la suppression de l'utilisateur : vous devez d'abord vider (fusionner vers l'utilisateur 0) les contributions d'un utilisateur A, puis supprimer l'utilisateur A.

Les pages déplacées sont journalisées dans Spécial:Journal/move
Pour les effacer de la journalisation de Journal/move, j'ai recréé les pages puis utilisé DeletePageForGood

L'extension crée un "journal de fusion d'utilisateur" et enregistre toutes les activités d'extension de fusion utilisateur. Consulter la page suivante Spécial:Journal/usermerge.
Les journalisations sont affichées sur la page Spécial:Modifications_récentes hors, ce n'est pas ce que j'attendais après avoir fusionné puis supprimé des comptes utilisateurs spammeurs.

# KO
Une solution intermédiaire serait de désactiver l'extension une fois que les merge et suppressions aient été effectuées.
Si l'extension est désactivée, "log-name-usermerge" s'affiche au lieu de "Journal des fusions de comptes d’utilisateurs".
Une seule ligne sera alors affichée dans les dernières modifications depuis Mediawiki  :  "18:25  	(⧼log-name-usermerge⧽)‎ . . [Zer00CooL‎ (46×)]"
Malgré tout, les pages que j'affiche sur un autre site avec un flux RSS continuent de servir les informations, une ligne pour chaque profil qui a été merge et supprimé.
Désactiver l'extension ne sert donc à rien. Je laisse l'extension activée.

# KO
L'extension wgLogRestrictions aurait pu permettre de ne pas afficher le journal de façon publique, mais, elle ne semble pas fonctionner correctement.
Consulter les notes de cette extension sur cette même page : Ne pas afficher les logs de suppression avec wgLogRestrictions.

# KO
Une autre alternative serait d'utiliser Lockdown mais la encore ça ne semble pas fonctionner.
Je ne suis pas sur des options à indiquer, je tente " usermerge " à interdire pour " user " mais les utilisateurs ont toujours accès aux informations de journalisation, notamment, sur " Dernières modifications ".
J'ai trouvé comment cacher toutes les " Dernières modifications " mais ce n'est pas l'objectif de cacher toutes les modifications, uniquement les merge et suppression de compte utilisateur.

# OK
L'extension RevisionDelete m'a permis de remplacer les informations de journalisation de UserMerge par des informations neutres.
J'aurais préféré pouvoir supprimer les informations de la journalisation de UserMerge mais l'extension RevisionDelete semble malgré tout intéressante. L'historique est conservé. Les informations non pertinentes sont neutralisées.

Il aurait sans doute été préférable d'utiliser le script CleanMediawiki.sh pour effacer proprement les utilisateurs spammeurs.

Restreindre la consultation des révisions

Manuel : https://www.mediawiki.org/wiki/Manual:RevisionDelete/fr

Renseigner le fichier LocalSettings.php avec les lignes suivantes pour pouvoir utiliser cette extension présente par défaut.

# Très pratique, ajoute une case à cocher à côté des lignes de journalisation. Cocher et appliquer la suppression va rendre le contenu affiché neutre.
# La raison de la journalisation n'est plus affichée publiquement. Les actions restent dans l'historique, et peuvent être à nouveau rendues visibles.
# Permet à Sysops de masquer les révisions et de journaliser les éléments des utilisateurs.
$wgGroupPermissions['sysop']['deletelogentry'] = true;
$wgGroupPermissions['sysop']['deleterevision'] = true;

Identifier et supprimer des pages en masse avec SmiteSpam

Aller sur la page spéciale SmiteSpam pour lancer une analyse du spam et obtenir une liste de pages identifiées comme spam.
Vous pouvez utiliser l'interface pour bloquer les utilisateurs, supprimer des pages ou encore faire confiance à un utilisateur pour modérer les spams avec vous.
La liste des utilisateurs de confiance peut être consultée et éditée dans les pages spéciales : SmiteSpamTrustedUsers.

Téléchargez et placez le (s) fichier (s) dans un répertoire appelé SmiteSpam dans vos extensions/ dossier.
https://github.com/wikimedia/mediawiki-extensions-SmiteSpam/archive/master.tar.gz

Ajouter le code suivant au bas de votre LocalSettings.php

Require_once " $IP /extensions/SmiteSpam/SmiteSpam.php" ;

Exécuter le script de mise à jour qui créera automatiquement les tables de base de données nécessaires à cette extension.
Vérifier dans les pages spéciales, Spécial: Version, sur votre wiki pour vérifier que l'extension est correctement installée.
Manuel Mediawiki : https://www.mediawiki.org/wiki/Extension:SmiteSpam

(N'est pas installé.)

Droit de l'utilisateur pour SmiteSpam

Par défaut cette extension ne peut être utilisée que par des sysops. Laisser aussi les bureaucrates l'utiliser en ajoutant la ligne suivante dans votre fichier "LocalSettings.php".

$WgGroupPermissions [ 'bureaucrat' ] [ 'smitespam' ] = true ;

Parameter	Default Value	Comment
$wgSmiteSpamThreshold	0.7	Pages analyzed as having a spam "probability" higher than this will be shown on special page.
$wgSmiteSpamIgnoreSmallPages	true	Should SmiteSpam ignore pages smaller than 500 characters?
$wgSmiteSpamIgnorePagesWithNoExternalLinks	true	Should SmiteSpam ignore all pages that don't have any external links outside of template calls?
$wgQueryPageSize	500	Number of pages to analyze in one AJAX request. (Setting this too high can cause timeouts.)
$wgDisplayPageSize	250	Number of pages to display in one paginated page.

Suppression définitive de page avec DeletePagesForGood

Permet à certains groupes de supprimer définitivement des pages de la base de données en ajoutant un nouvel onglet de suppression à chaque page.

Télécharger DeletePagesForGood : https://github.com/wikimedia/mediawiki-extensions-DeletePagesForGood/archive/master.tar.gz
Placer le contenu téléchargé dans un répertoire appelé DeletePagesForGood dans votre dossier extensions/.
Ajouter le code suivant au bas de votre fichier de configuration LocalSettings.php pour activer l'extension DeletePagesForGood : WfLoadExtension ( 'DeletePagesForGood' );
Accéder à Pages spéciales pour vérifier que l'extension DeletePagesForGood est correctement installée.

L'extension DeletePagesForGood est installée et fonctionne parfaitement sur Mediawiki 1.28.0.
Un bogue est relevé sur la version 1.29.1 et il n'est plus possible de supprimer les pages déjà existantes avec DeletePagesForGood.
Pour supprimer une page, supprimer la page normalement, recréer la page, supprimer alors définitivement la page avec DeletePagesForGood.
Voir le suivi de la conversation : https://www.mediawiki.org/wiki/Extension_talk:DeletePagesForGood

Suivi du Ticket de maintenance pour DeletePagesForGood : https://phabricator.wikimedia.org/T113883

Droits des utilisateurs

Dans le fichier LocalSettings.php vous pouvez modifier les droits d'utilisateur.

Les valeurs par défaut de DeletePagePermanently.php sont présentées dans le code suivant.
L'extension introduit un nouveau droit d'utilisateur deleteperm.
$WgGroupPermissions [ '*' ] [ 'deleteperm' ] = false ;
$WgGroupPermissions [ 'user' ] [ 'deleteperm' ] = false ;
$WgGroupPermissions [ 'bureaucrate' ] [ 'deleteperm' ] = false ;
$WgGroupPermissions [ 'sysop' ] [ 'deleteperm' ] = true ;

Espaces de noms

Pour le configurer, ajoutez quelques lignes à votre LocalSettings.php :

$WgDeletePagesForGoodNamespaces = array (NS_MAIN => true, NS_IMAGE => true, NS_IMAGE_TALK => true, NS_CATEGORY => true, NS_CATEGORY_TALK => true, NS_TEMPLATE => true, NS_TEMPLATE_TALK => true, NS_TALK => true, NS_USER => true, NS_USER_TALK => true, NS_FILE => true, NS_FILE_TALK => true);

Un wiki utilisant le logiciel MediaWiki compte 18 espaces de noms par défaut pour structurer le contenu.

Un espace de noms principal, où les noms de page n'ont pas de préfixe.

Quinze Espaces de noms supplémentaires, chacun avec son propre préfixe, par exemple «Utilisateur:» ou bien «Discussion:» ce qui permet à plusieurs pages d'exister sous le même nom à l'espace de nom près mais avec des finalités différentes selon le préfixe. La page intitulée « Mediawiki » peut décrire l'utilisation de l'outil, tandis que la page « Utilisateur:Mediawiki » peut être une page personnelle décrivant un utilisateur ayant choisi ce pseudonyme. Chaque page de Mediawiki est associée à une page de discussion qui a pour but de permettre aux utilisateurs de discuter du sujet de la page.

Deux espaces de noms virtuels.

En savoir plus sur les espaces de noms : https://meta.wikimedia.org/wiki/Namespaces

Correctifs pour corriger des difficultés de fonctionnement

Error CDB

[WRhGctmgP7UAAGqqTN4AAAAh] 2017-05-14 11:58:44: Fatal exception of type MWException

Fatal error: Uncaught exception 'Cdb\Exception' with message 'Unable to move the new CDB file into place.' in /homepages/38/d548381562/htdocs/CLPublic/wiki/vendor/wikimedia/cdb/src/Writer/DBA.php:60 Stack trace: #0 /homepages/38/d548381562/htdocs/CLPublic/wiki/vendor/wikimedia/cdb/src/Writer.php(88): Cdb\Writer\DBA->close() #1 [internal function]: Cdb\Writer->__destruct() #2 {main} thrown in /homepages/38/d548381562/htdocs/CLPublic/wiki/vendor/wikimedia/cdb/src/Writer/DBA.php on line 60

[Résolu] avec l'ajout de la ligne $wgTmpDirectory = "$IP/tmp"; dans le fichier LocalSettings.php et la création du dossier /tmp à la racine du wiki.

Source - Error writing to CDB file when several MediaWiki installations use the same tmp directory : https://phabricator.wikimedia.org/T127127

Erreur lors de la création de miniature

# Erreur lors de la création de la miniature : Impossible d'enregistrer la vignette sur la destination.
# Ajouter la ligne suivante dans le fichier LocalSettings.php.
$wgTmpDirectory = "$IP/images/temp";

Erreur mw-UIDGenerator-UID-nodeid dans le répertoire /tmp du système linux

# Le fichier mw-UIDGenerator-UID-nodeid est créé dans le répertoire /tmp du système car aucune configuration ne spécifie le répertoire temporaire de Mediawiki.

# Si se dossier se trouve dans le répertoire de MediaWiki, cela signifie qu'il est accessible si quelqu'un tape www.site.com/tmp
# Idéalement, il devrait être situé en dehors du répertoire du site pour réduire les vecteurs d'attaques pour éviter le téléchargement et l'exécution de scripts depuis le navigateur.
# Si la racine du document se trouve dans /var/www/html/, voir à ajouter le répertoire temporaire dans /var/www/tmp/ en donnant les autorisations à Apache2.
# Restreindre l'accès Web à ce répertoire avec une configuration .htaccess ou depuis le VirtualHost.

cd /var/www/
sudo mkdir tmp_mediawiki
sudo chmod 750 -R tmp_mediawiki/
sudo chown -R www-data:www-data tmp_mediawiki/
ls
drwxr-x---  2 www-data www-data   4096 avril  8 04:11 tmp_mediawiki
cd /var/www/tmp_mediawiki/
sudo echo "Require all denied" > .htaccess
sudo chown www-data:www-data .htaccess

# Ajouter la ligne suivante dans le fichier LocalSettings.php du site Mediawiki :
$wgTmpDirectory="/var/www/tmp_mediawiki/";

cd /var/www/tmp_mediawiki/
ls
mw-UIDGenerator-UID-nodeid  mw-UIDGenerator-UUID-128

# Les deux fichiers continuent d'être créés par Mediawiki, mais, ils ne sont maintenant plus écrits dans le répertoire système.
# Ils ne sont pas non plus écrits dans un répertoire public accessible via navigateur, comme le permet ce wiki : http://wiki.td-er.nl/images/tmp/
# Le numéro contenu dans mw-UIDGenerator-UID-nodeid est statique et ne semble pas être modifié une fois celui-ci créé.
# A suivre pour identifier l'usage de ses deux fichiers.

Protéger le dossier images

# Le répertoire par défaut pour les téléchargements /var/www/wiki.visionduweb.fr/images/ est vulnérable car il peut exécuter n'importe quel script.
# Suivre la procédure de sécurité pour protéger le dossier images : https://www.mediawiki.org/wiki/Manual:Security#Upload_security

sudo chown -R www-data:www-data images/
/var/www/wiki.visionduweb.fr$ sudo chmod -R 755 images/
/var/www/wiki.visionduweb.fr$ sudo chmod -x+X images/ -R

# Ajouter dans le fichier .htaccess ou Virtualhost :
<Directory /var/www/wiki/images>
Options -Indexes
</Directory>

# Pense bête :
       u (user, utilisateur) représente la catégorie "propriétaire" ;
       g (group, groupe) représente la catégorie "groupe propriétaire" ;
       o (others, autres) représente la catégorie "reste du monde" ;
       a (all, tous) représente l'ensemble des trois catégories.
# La modification que l'on veut faire
       + : ajouter
       - : supprimer
       = : affectation
# Le droit que l'on veut modifier
       r : read ⇒ lecture
       w : write ⇒ écriture
       x : execute ⇒ exécution
       X : eXecute ⇒ exécution, concerne uniquement les répertoires (qu'ils aient déjà une autorisation d'exécution ou pas) et les fichiers qui ont déjà une autorisation d'exécution pour l'une des catégories d'utilisateurs. Nous allons voir plus bas dans la partie des traitements récursifs l'intérêt du X.

Source : https://doc.ubuntu-fr.org/permissions

Configurer le .htaccess de MediaWiki

URL raccourcies

Les adresses de page par défaut de MediaWiki :
https://wiki.visionduweb.fr/index.php/Accueil (les versions récentes de MediaWiki, sans le support CGI)
https://wiki.visionduweb.fr/index.php?title=Accueil (les versions récentes de MediaWiki, avec le support CGI)

Source : https://www.mediawiki.org/wiki/Manual:Short_URL/fr
Source : https://www.mediawiki.org/wiki/Manual:Short_URL/Apache

Mettre en place une URL du type domaine.ext/wiki/Accueil avec le fichier .htaccess

N'a pas fonctionné lors de mon dernier essai sur le VPS mais ce code devrait normalement être fonctionnel.
Mediawiki doit être installé dans le dossier wiki à la racine du domaine.

Étape 1 - Renseigner le fichier htaccess

# Ajouter cette règle dans le fichier .htaccess pour avoir des URL raccourcies.
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/wiki/index.php [L]

Étape 2 - Renseigner le fichier LocalSetting.php

# Ligne présente par défaut à conserver : $wgScriptPath = "/wiki";

# Lignes pour permettre le rewrite :
# $wgArticlePath = "{$wgScriptPath}/$1";
# $wgScriptExtension  = ".php";
# $wgUsePathInfo = true;

Réécriture des adresses URL de Mediawiki

Dans le cas ou le wiki est dans un dossier wiki

# Mettre en place une URL du type domaine.ext/wiki/index.php?title=Accueil
# Réécrire l'url par défaut depuis le fichier LocalSettings.php et sans avoir à utiliser de redirection ".htaccess".
$wgArticlePath = "/wiki/index.php?title=$1";
$wgScriptExtension = ".php";
$wgUsePathInfo = true;

Dans le cas ou le wiki est à la racine du domaine

# Mettre en place une URL du type domaine.ext/index.php?title=Accueil
# Il est actuellement nécessaire de forcer ce paramétrage depuis le fichier LocalSettings.php en dé-commentant le code suivant.

# Réécrire l'url par défaut depuis le fichier LocalSettings.php pour le mediawiki en production et sans avoir à utiliser de redirection ".htaccess".
$wgArticlePath = "/index.php?title=$1";
$wgScriptExtension = ".php";
$wgUsePathInfo = true;

# Les versions récentes de MediaWiki, avec le support CGI, utilisent ce type d'adresse : /index.php?title=Accueil
# Ce type de lien devrait être le comportement par défaut du wiki de visionduweb : https://wiki.visionduweb.fr/index.php?title=Accueil
# Si ce code est commenté, l'adresse affichée sera du type : https://wiki.visionduweb.fr/index.php/Accueil

Minifier les adresses de Mediawiki

Un assistant pour modifier le code .htaccess : https://shorturls.redwerks.org

Forcer la redirection des adresses

# L'adresse suivante semble intéressante visuellement : https://wiki.visionduweb.fr/index.php/Accueil
# Malgré tout, les commandes Mediawiki sont habituellement disponibles depuis les exemples de ce type : https://wiki.visionduweb.fr/index.php?title=Accueil

# Voir à mettre en place une redirection des adresses du type index.php/Accueil vers index.php?title=Accueil !

Surcouche de sécurité Aesecure

Installer une surcouche de sécurité Aesecure sur MediaWiki.

Le changement de mail et de mot de passe des utilisateurs de Mediawiki est bloqué par Aesecure

# Le changement de mail et de mot de passe des utilisateurs de Mediawiki est bloqué par Aesecure.

Erreurs pouvant être rencontrées

Impossible de charger une image dans Mediawiki

Could not create directory "mwstore://local-backend/local-public".' on file upload
# Ou :
mediawiki Impossible d'ouvrir le fichier de verrou pour « mwstore://local-backend/local-public

# Il s'agit d'un problème de droits sur le dossier images/ :
sudo chmod -R 755 images/
sudo chown -R www-data. images/

# Résolu.

# En cas de problème lié à l'open_basedir :
https://www.mediawiki.org/wiki/Topic:Rlhpjydczdfblix3
https://www.mediawiki.org/wiki/Manual:Configuring_file_uploads

Bibliographie

MediaWiki – Quelques astuces et personnalisations : https://www.demoniak.ch/mediawiki-quelques-astuces-et-personalisations/
 Comment devenir un Hacker de Mediawiki : https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/fr

Options du fichier LocalSettings.php : https://doc.wikimedia.org/mediawiki-core/master/php/DefaultSettings_8php.html
Le code source officiel de Mediawiki : https://doc.wikimedia.org/mediawiki-core/master/php/MysqlUpdater_8php_source.html
Le code source de Mediawiki sur Github : https://github.com/wikimedia/mediawiki

Semantic MediaWiki : https://sourceforge.net/p/semediawiki/mailman/semediawiki-user/

NAVIGATION

PARTICIPER ET PARTAGER Bienvenue sur le wiki de DIDAQUEST. De nombreuses pages sont partagées sur ce wiki. Créer un compte utilisateur pour participer sur ce wiki. Les pages présentées sur le wiki évoluent tous les jours. Certaines recherches sont peu abouties et incluent des erreurs. Utiliser la recherche interne de ce wiki pour trouver votre contenu. La page de discussion de Didaquest vous permet de poser une question. Utiliser la recherche interne du site pour chercher dans tout le contenu. Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique. Protéger votre système Linux ou Windows en lisant la page dédié à la sécurité. Améliorer le contenu des pages avec vos propositions depuis l'onglet discussion.

SOUTENIR CE WIKI Soutenir le wiki avec un don en EDUTOKEN ou avec une autre monnaie numérique : AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash OBTENIR DE LA MONNAIE NUMERIQUE Obtenir gratuitement de la monnaie numérique : Gagner des Altcoins - Miner des Altcoins.