Modération (Veritesauver)

Veritesauver est le composant de modération de Verité. Il contient le système de sanctions maison (bannissements, sourdines, avertissements, expulsions et sanctions IP), l’arbre de sanctions par pointer-cliquer, la barrière de vérification par captcha, les renseignements sur les comptes (détection d’alts et historique des IP et des noms), la recherche de pays GeoIP, le verrouillage du serveur, l’observation de l’inventaire et du coffre de l’Ender, et le contrôle du chat (diffusion, effacement, sourdine et mode lent).

L’ensemble du composant peut être activé ou désactivé indépendamment du reste de Verité.

moderation:
  enabled: true

Tant que la modération est désactivée, chaque commande de modération du personnel est refusée.

Où trouver les commandes et les permissions

Cette page explique ce que fait chaque fonctionnalité. Pour la syntaxe exacte des commandes, voir la Référence des commandes. Pour chaque nœud de permission, voir la Référence des permissions. Les développeurs intégrant un système de chat personnalisé devraient plutôt lire Application de la modération personnalisée.

Sanctions

Chaque bannissement, sourdine, avertissement et expulsion est un enregistrement de la même forme : qui a été sanctionné, qui l’a émis, la raison, les heures de début et de fin, s’il était silencieux, et s’il est toujours actif. Les enregistrements ne sont jamais modifiés sur place. Lever une sanction inscrit qui l’a retirée et pourquoi, et conserve l’original comme historique, de sorte que la trace de modération complète d’un joueur est toujours intacte.

Toutes les sanctions passent par un moteur unique, de sorte qu’une sanction émise par une commande, par l’arbre de sanctions ou par une intégration se comporte toujours de la même manière : elle est appliquée, annoncée au bon personnel et enregistrée de façon cohérente.

Bannissements et sourdines

  • Un bannissement empêche un joueur de se connecter. Il est appliqué à l’écran de connexion, de sorte qu’un joueur banni est refusé avant même d’apparaître.
  • Une sourdine empêche un joueur de parler dans le chat. Un joueur réduit au silence qui tente de parler voit un bref rappel du temps qu’il reste à sa sourdine.
  • Les deux peuvent être permanents ou minutés. Les sanctions minutées expirent d’elles-mêmes.
  • Émettre un nouveau bannissement ou une nouvelle sourdine par-dessus un existant du même type le remplace proprement. L’ancien enregistrement est conservé comme historique, et exactement une sanction active demeure.

Sanctions IP

Un bannissement IP ou une sourdine IP couvre l’adresse plutôt qu’un seul compte, il s’applique donc à chaque compte se connectant depuis cette adresse. Cela attrape un joueur qui tente d’échapper à une sanction de compte en se connectant sur un compte secondaire depuis la même connexion.

Expulsions

Une expulsion déconnecte immédiatement un joueur en ligne. Elle laisse un enregistrement pour l’historique mais n’empêche pas le joueur de se reconnecter.

Lever des sanctions

Le personnel lève un bannissement ou une sourdine avec les commandes unban et unmute. Un modérateur ne disposant que de la forme « own » de la permission unban ou unmute ne peut lever que les sanctions qu’il a émises lui-même, ce qui permet au personnel senior de déléguer un pouvoir de grâce limité.

Messages de sanction

Le texte que voit un joueur sanctionné est rédigé dans la configuration, de sorte que les propriétaires peuvent réécrire chaque message. Les modèles prennent en charge des placeholders qui sont remplis pour chaque sanction spécifique :

Placeholder Rempli avec
@duration La durée lisible par un humain (vide pour une sanction permanente).
@enforcer Le membre du personnel qui a émis la sanction.
@target Le joueur sanctionné.
@reason La raison, ou « No reason provided. » lorsque aucune n’a été donnée.
@punishment L’action sous forme verbale.
@total.warns Le nombre d’avertissements actifs du joueur sanctionné.

Utilisez \n dans un modèle pour un retour à la ligne.

moderation:
  punish.message.templates:
    ban.template.temporary: {You have been banned for @duration.\n@reason}
    ban.template.permanent: {You have been permanently banned.\n@reason}
    mute.template.temporary: {You have been muted by @enforcer for @duration.\n@reason}
    mute.notice: {You are muted. Time remaining: @remaining}

Limites et délais d’attente par rang

Le personnel est tenu à un plafond par rang sur la durée d’un bannissement ou d’une sourdine temporaire qu’il peut émettre, et à un délai d’attente par rang sur la fréquence à laquelle il peut sanctionner. Un membre du personnel n’est jamais bloqué net pour avoir demandé une durée trop longue : la demande est simplement ramenée au plafond de son rang, de sorte que la sanction s’applique quand même, juste plus courte. Les opérateurs et les détenteurs de la permission admin sont exemptés à la fois des plafonds et du délai d’attente.

Détail technique

Les paliers de rang (durées et délai d’attente) sont actuellement intégrés en dur plutôt que lus depuis la configuration, et le suivi du délai d’attente se réinitialise lorsque le serveur redémarre.

Arbre de sanctions

L’arbre de sanctions est un menu par pointer-cliquer qui permet au personnel de sanctionner un joueur à partir d’une liste croissante de catégories d’infractions sans mémoriser de commandes ni de durées.

Exécuter la commande punish ouvre une page de joueurs en ligne, chacun affiché sous sa propre tête. Cliquer sur un joueur passe aux catégories d’infractions. Fournir un nom de joueur d’emblée saute la page des joueurs et va droit aux catégories.

La page des catégories montre une icône pour chaque type d’infraction sur lequel le rang du membre du personnel est autorisé à agir. Cliquer sur une catégorie ouvre une confirmation qui montre la sanction exacte que l’arbre a choisie pour ce joueur et cette infraction. La peine choisie gravit une échelle à mesure que le même joueur récidive dans la même catégorie : un premier spam pourrait être un avertissement, et un ultérieur une sourdine ou un bannissement, de sorte que le personnel n’a jamais à se souvenir de la bonne durée.

La confirmation offre trois boutons :

  • Annuler (rouge) ferme le menu.
  • Approuver (vert) applique la sanction choisie et fait avancer l’échelle d’escalade.
  • Manuel (bleu clair) laisse le membre du personnel choisir lui-même la sanction. Sur les serveurs assez récents, c’est un formulaire de saisie natif ; sur les serveurs plus anciens, c’est une invite de chat cliquable. Un choix manuel ne fait pas avancer l’échelle.

L’escalade est comptée par joueur, par catégorie, et est mémorisée à travers les redémarrages. Un membre du personnel ne peut agir que sur les catégories accordées à son rang dans la configuration, et le menu entier est indisponible tant que l’arbre est désactivé.

Configurer l’arbre

Chaque catégorie porte une échelle ordonnée d’étapes et un objet Minecraft utilisé comme son icône d’interface. Une étape est une sanction appliquée à un compte d’infractions donné : warn, kick, mute, mute: 10m, ban ou ban: 14d. Une étape sans durée est permanente.

Le bloc permissions.luckperms associe un rang aux catégories sur lesquelles ce rang peut agir. L’héritage suit l’ordre listé du moins au plus privilégié, de sorte qu’un rang supérieur hérite des catégories des rangs au-dessus de lui dans la liste.

moderation:
  tree:
    enabled: true
    permissions:
      luckperms:
        helper: {harassment, threats, spam, advertising}
        mod: {exploiting, discrimination, impersonation}
        admin: {hacking, fraud, evading.punishment}
    categories:
      spam: {warn, mute: 10m, mute: 1h, ban: 3d, ban, minecraft:cactus}
      harassment: {kick, ban: 14d, ban, minecraft:nether_star}
  use.fields: true

Réglez use.fields sur true pour présenter la dérogation manuelle sous forme de formulaire de saisie natif de Minecraft sur Minecraft 1.21.7 et plus récent, ou sur false pour toujours utiliser l’invite de chat cliquable.

Avertissements

Le personnel émet des avertissements, révoque le plus récent et inspecte les avertissements actifs par joueur ou à l’échelle du serveur. Un avertissement n’est pas appliqué en soi : c’est une pénalité qui se dissipe. Un avertissement compte comme actif jusqu’à ce qu’il se périme, après quoi il ne compte plus dans le total actif.

moderation:
  expire.warns.after: 7d

Actions de seuil automatiques

Lorsque le nombre d’avertissements actifs d’un joueur atteint un seuil défini, le serveur agit de lui-même afin que le personnel n’ait pas à suivre les pénalités à la main. D’emblée, atteindre trois avertissements actifs réduit le joueur au silence pour un jour, et en atteindre cinq le bannit temporairement pour un jour. Chaque seuil ne se déclenche qu’à son compte exact, de sorte qu’un seul avertissement déclenche au plus une action. Le personnel configuré pour recevoir des notifications voit une annonce nommant le joueur et le compte qu’il a atteint.

Détail technique

Les seuils et leurs actions sont actuellement intégrés en dur (trois avertissements pour une sourdine d’un jour, cinq pour un tempban d’un jour) plutôt que configurables.

Barrière de captcha

Le système de captcha force un joueur à compléter un défi de vérification, soit automatiquement lorsqu’un signal fort de comportement automatisé est présent, soit manuellement lorsque le personnel en émet un. Un joueur exempté via la permission de contournement n’est jamais soumis à un captcha.

Il y a deux variantes :

  • Standard est la vérification la plus légère. Le joueur se voit présenter un menu de coffre et on lui demande de cliquer sur un objet nommé parmi une grille de leurres. Cliquer sur le mauvais objet compte contre lui, et cinq mauvais clics font échouer. Le menu se rouvre s’il est fermé, le joueur est maintenu sur place, et la tentative échoue après 30 secondes. Cela n’aveugle ni ne ralentit le joueur et ne prend pas le contrôle de son inventaire.
  • Détaillé est la vérification la plus forte. Un code aléatoire de cinq caractères est dessiné sur un objet carte que le joueur tient, et il doit retaper le code dans le chat. Pendant qu’il est actif, le joueur est épinglé sur place, aveuglé et ralenti, et ne peut pas se déplacer, jeter des objets ni ouvrir son inventaire, de sorte que la seule action possible est de taper le code. Taper exit abandonne, trois mauvaises tentatives font échouer, et la tentative expire après 60 secondes. L’inventaire et la position réels du joueur sont sauvegardés et restaurés lorsque le défi se termine.

Lorsqu’un défi se conclut, le résultat (réussite, échec ou expiration) est annoncé au personnel détenant la permission de notification de captcha. Un joueur qui échoue ou dont le temps expire est expulsé.

Le personnel peut forcer un défi sur un joueur ou sur chaque joueur éligible à la fois avec la commande captcha, en choisissant la variante standard ou détaillée.

Renseignements sur les comptes

Chaque connexion est enregistrée : le nom du joueur, son IP de connexion, la marque de son client et sa version de protocole. Cela construit une trace d’identité durable qui alimente les commandes de recherche et les alertes automatiques au personnel.

Derrière un proxy

Verité résout la véritable IP client du joueur d’une manière consciente du proxy, faisant confiance d’abord à une poignée de main de style TCPShield et jamais à l’adresse socket propre du proxy. C’est ce qui garde la détection d’IP partagées et les recherches de pays exactes sur un réseau proxifié.

Recherches

Le personnel dispose d’un ensemble de commandes d’enquête en lecture seule :

  • History et staff history listent les sanctions qu’un joueur a reçues ou qu’un membre du personnel a émises.
  • Ban list et mute list parcourent page par page les sanctions actuellement actives de chaque type.
  • Duplicate IP scan liste les comptes qui partagent une IP avec un joueur donné et signale ceux qui sont actuellement bannis ou réduits au silence, faisant remonter les comptes secondaires probables. Le nombre de comptes affichés est plafonné.
  • IP history, name history et last UUID font remonter la trace d’identité stockée d’un joueur.
  • Staff rollback lève en bloc les sanctions actives récentes d’un membre du personnel, et prune history supprime les enregistrements inactifs d’un joueur.
  • Seen indique la dernière fois qu’un joueur était en ligne.
  • Whois construit un dossier de compte complet : identité, noms passés, client et version, référent, pays, temps de jeu, et première et dernière connexions. Si le nom n’a jamais touché ce serveur, Verité le résout via Mojang afin que le personnel puisse tout de même rechercher un vrai compte. La dernière IP exacte est protégée par sa propre permission.
moderation:
  shared.ip.scan.limit: 20

Politique de détection d’alts

Par défaut, un alt n’est attrapé que par une sanction IP. Activer la politique de bannissement d’alts fait qu’un bannissement couvre automatiquement les autres comptes partageant l’IP du joueur banni, même sans bannissement IP explicite.

moderation:
  auto.ban.alts: false

Connexions partagées

N’activez pas la politique de bannissement d’alts sur un serveur où plusieurs joueurs distincts partagent une adresse IP (par exemple, des joueurs derrière le même foyer ou un réseau partagé), car elle peut attraper des comptes innocents.

Alertes de connexion automatiques

Le personnel détenant la permission de notification pertinente est alerté automatiquement lorsqu’un joueur signalé se connecte :

  • Connexion d’un banni : un joueur banni, un joueur banni par IP ou un alt banni est refusé à l’écran de connexion. L’alerte nomme le joueur et le temps qu’il reste au bannissement.
  • Connexion d’une IP dupliquée : un joueur qui se connecte partage une IP avec d’autres comptes. L’alerte liste les autres comptes et marque ceux qui sont bannis ou réduits au silence.
  • Connexion d’un client non vanilla : un joueur qui se connecte est sur un client modifié tel que Fabric ou Forge. L’alerte nomme le joueur et la marque de client qu’il rapporte. Un client vanilla est silencieux.

Application en réseau et par proxy

Sur un réseau à plusieurs serveurs, Verité peut appliquer les bannissements et les mutes au niveau du proxy, de sorte qu'un joueur sanctionné est arrêté à la lisière du réseau, avant qu'il n'atteigne le moindre serveur backend. C'est optionnel et désactivé par défaut : un serveur unique n'en a aucun besoin.

Verité stocke toutes les données dans H2 et rien d'autre n'est requis pour les partager. La même base de données H2 est ouverte par chaque backend et par le proxy ; votre base de données existante est utilisée telle quelle, sans étape de conversion lors de la mise à jour.

Comment la base de données est partagée

Un serveur possède le fichier de la base de données et le sert au reste du réseau via le propre mode réseau de H2. Chaque backend lit et écrit les données partagées ; le proxy ne fait que les lire.

  • embedded est la valeur par défaut : un serveur unique avec son propre fichier de base de données local. Correct lorsque vous n'exécutez pas un réseau avec proxy.
  • host fait que ce backend possède le fichier de la base de données et le sert au réseau. Exécutez exactement un host par réseau.
  • remote fait que ce backend se connecte au host via le réseau. Indiquez l'adresse du host.
database:
  mode: embedded
  port: 9092
  host.address: "127.0.0.1:9092"
  auto.server: false

Lorsqu'un backend et le proxy partagent la même machine et le même fichier, auto.server permet au mode embedded de servir le fichier sans host dédié. Laissez-le désactivé sauf si vous exécutez un réseau sur une seule machine.

Les sanctions concurrentes sont sûres

Plusieurs backends peuvent émettre des sanctions en même temps contre la base de données partagée sans que l'une n'efface l'autre, et lever une sanction n'est jamais annulé par une copie obsolète sur un autre serveur. Un bannissement ou un mute émis sur un backend est visible par tous les autres backends et par le proxy.

Le plugin du proxy

Le même jar de Verité s'exécute sur Velocity et sur BungeeCord ou Waterfall. Déposez-le dans le dossier des plugins du proxy comme n'importe quel autre plugin de proxy.

Le proxy est strictement en lecture seule : il n'enregistre jamais de connexions, n'émet aucune sanction et n'écrit rien dans la base de données partagée. Il réutilise la propre logique de sanctions de Verité, donc un bannissement résolu au niveau du proxy est exactement la même décision qu'un backend prendrait, couvrant les bannissements directs, les bannissements d'IP et les alts bannis.

  • Un joueur banni est refusé à la connexion du proxy et voit l'écran de bannissement, il n'atteint donc jamais un backend.
  • Le chat d'un joueur mute est bloqué au niveau du proxy. Les commandes bloquées en cas de mute le sont aussi, ce qui comble la faille où un proxy traite une commande avant qu'un backend ne la voie.
database.mode=remote
database.host.address=127.0.0.1:9092
moderation.ban.alts=false
moderation.enforce.mute.commands=true

La configuration du proxy se trouve dans verite-proxy.properties, dans le dossier de données Verité du proxy, écrite avec des valeurs par défaut raisonnables au premier démarrage. Pointez database.host.address vers le backend exécuté en mode host, et assurez-vous que le proxy peut atteindre ce port.

GeoIP

Verité peut attacher un pays à une adresse IP, utilisé par whois et la commande geoip. Donnez-lui un nom de joueur pour utiliser son IP stockée la plus récente, ou une adresse IP directement.

La recherche de pays utilise une base de données MaxMind GeoLite2-Country. Si aucune base de données n’est présente, Verité le dit clairement plutôt que de rapporter un pays erroné ou inconnu. Les adresses privées et de bouclage ne peuvent jamais être résolues, quelle que soit la base de données.

Utiliser une base de données officielle

Pour utiliser une base de données MaxMind officielle, déposez GeoLite2-Country.mmdb dans le dossier de données du plugin. Verité ne télécharge une base de données de substitution que lorsque le fichier est absent, de sorte qu’un fichier existant n’est jamais écrasé.

Verrouillage du serveur

Le verrouillage scelle le serveur pendant une urgence telle qu’un raid ou un exploit exploité, sans bannir aucun joueur individuel. Tant que le verrouillage est activé, toute personne tentant de se connecter est refusée à l’écran de connexion et voit la raison définie par le personnel. Le personnel de confiance disposant de la permission de contournement de verrouillage peut tout de même entrer pour gérer la situation.

Le verrouillage est une posture d’urgence temporaire, non un réglage durable : il ne dure que jusqu’au redémarrage du serveur, de sorte qu’un redémarrage l’efface toujours et que le serveur ne peut jamais être laissé accidentellement inaccessible après son retour. Le personnel le démarre et l’arrête avec la commande lockdown et peut donner une raison personnalisée que les joueurs verront.

Observation de l’inventaire et du coffre de l’Ender

L’observation est un outil du personnel pour regarder à l’intérieur des affaires d’un autre joueur. Ouvrir la commande d’observation d’inventaire sur un joueur montre tout ce qu’il transporte : barre d’accès rapide et rangement principal, armure, main secondaire, et même les emplacements de fabrication ou de poste de travail qu’il a actuellement ouverts. La commande d’observation de l’Ender fait de même pour son coffre de l’Ender.

  • Avec la permission d’édition, un observateur peut déplacer des objets vers l’intérieur et l’extérieur, et le changement se produit chez la cible immédiatement.
  • Avec seulement la permission de consultation, la fenêtre est en lecture seule.
  • Un observateur avec la permission no-takeout peut déposer des objets mais jamais en retirer, ce qui permet au personnel de rang inférieur de réorganiser ou de déposer sans pouvoir voler.

L’observation fonctionne aussi sur les joueurs hors ligne, en lisant leurs données sauvegardées et en réinscrivant toute modification lorsque la fenêtre est fermée. Certains joueurs peuvent être marqués comme protégés afin qu’on ne puisse pas les espionner, à moins que l’observateur ne soit autorisé à contourner cette protection.

Chaque session est annoncée à la console : une ligne lorsqu’un membre du personnel ouvre une fenêtre, une liste de exactement ce qui a changé si quoi que ce soit a été ajouté ou retiré, et une ligne lorsque la fenêtre est fermée. Un observateur qui ne fait que regarder et ne change rien ne produit que les lignes d’ouverture et de fermeture.

Noms familiers

Les commandes et les nœuds de permission reprennent l’InvSee++ d’origine, de sorte que les habitudes du personnel existant et les attributions de permissions continuent de fonctionner. Voir la Référence des permissions pour les nœuds d’observation.

invsee:
  enable-offline-player-support: true
  enable-unknown-player-support: true
  tabcomplete-offline-players: true
  • enable-offline-player-support autorise la consultation des joueurs qui ne sont pas actuellement en ligne.
  • enable-unknown-player-support autorise la consultation des comptes qui n’ont jamais rejoint ce serveur.
  • tabcomplete-offline-players inclut les noms hors ligne dans l’autocomplétion.

Contrôle du chat

Verité fournit les contrôles collectifs de modération du chat. Le personnel disposant de la permission de contournement du chat n’est jamais affecté par la sourdine du chat ni par le mode lent.

Diffusion

La diffusion envoie une annonce du personnel à tout le serveur. Le message apparaît dans le chat de tous, mis en évidence avec le préfixe du serveur et une ligne vide au-dessus et en dessous afin qu’il ressorte. Utilisez-la pour des rappels, des annonces d’événements ou des annonces de règles.

Effacement du chat

L’effacement du chat pousse la conversation récente vers le haut et hors de vue pour chaque joueur, puis annonce qui l’a effacée. C’est utile pour effacer du spam ou réinitialiser une dispute. Il n’efface que ce que les joueurs voient actuellement ; il ne supprime aucun journal sauvegardé.

Sourdine du chat

La sourdine du chat bascule un gel du chat à l’échelle du serveur. Tant qu’elle est activée, les joueurs ordinaires ne peuvent pas envoyer de messages et se voient dire que le chat est en sourdine s’ils essaient, ce qui est utile pour apaiser un moment tendu ou retenir l’attention pendant une annonce. Exécuter la commande de nouveau rétablit le chat. Le personnel disposant de la permission de contournement peut toujours parler.

Mode lent

Le mode lent fixe un délai minimal entre les messages de chat. Donnez-lui une durée telle que 10s, 5m ou 2h, et chaque joueur doit attendre ce délai entre les messages ; s’il essaie de parler trop tôt, on lui indique combien de temps il reste. Ajoutez un nom de joueur pour appliquer un mode lent personnel à une seule personne au lieu de tout le monde. Utilisez off pour l’effacer, soit globalement, soit pour un joueur nommé. Un mode lent personnel a priorité sur celui à l’échelle du serveur, et le mode lent maximal est de 24 heures.

Liste noire de commandes pour les joueurs réduits au silence

Un joueur réduit au silence est empêché de faire passer du chat par des commandes telles que /msg ou /me. Lorsqu’un joueur réduit au silence exécute une commande de la liste noire, elle est annulée et sa raison de sourdine lui est de nouveau montrée. La liste noire est configurable.

moderation:
  muted.command.blacklist:
    - "me"
    - "say"
    - "msg"
    - "tell"
    - "r"

Réseaux avec proxy

Si votre serveur est hébergé sur un réseau avec injection par proxy, ces commandes peuvent être gérées par le proxy avant qu'un backend ne les voie, auquel cas un joueur réduit au silence pourrait tout de même les utiliser. Exécutez le plugin de proxy de Verité pour combler cette faille : voir Application en réseau et par proxy. Pour une configuration de chat ou de proxy personnalisée, voir Application de la modération personnalisée.

Exemptions et protection de rang

Verité vérifie qui ne peut pas être sanctionné avant d’appliquer toute sanction.

  • Exemption par permission : une cible détenant la permission exempt ne peut pas être sanctionnée à moins que l’émetteur ne détienne la permission exempt-bypass. L’exemption peut être portée sur un type de sanction, de sorte qu’un joueur exempté des bannissements peut tout de même être réductible au silence.
  • Protection de rang : lorsqu’elle est activée, un émetteur ne peut pas sanctionner une cible dont le poids de groupe LuckPerms est égal ou supérieur au sien, de sorte que le personnel ne peut pas sanctionner ses pairs ou ses supérieurs. Un opérateur est toujours traité comme le rang le plus élevé, de sorte qu’un non-opérateur ne peut jamais sanctionner un opérateur et qu’un opérateur peut toujours sanctionner. La console n’est jamais bloquée.
moderation:
  use.rank.weights: true
  exempt:
    use.group.weights: false
    permit.same.weight: true

Détail technique

Les vérifications de permission et de rang ne s’appliquent qu’aux cibles en ligne, car les permissions en direct d’un joueur hors ligne ne peuvent pas être lues. LuckPerms est facultatif : en son absence, la comparaison de poids passe et ne bloque jamais le personnel.