Vous êtes administrateur d’un serveur fonctionnant sous Bukkit et vous souhaitez installer un système de permissions, quasiment indispensable, mais vous n’y arrivez-pas ? Vous ne comprenez rien à ce système de « nodes », votre fichier de configuration ne fonctionne pas ou tout simplement vous n’avez pas le temps de vous y pencher ? Si vous êtes dans ce cas, alors ce guide complet sur les permissions sous Bukkit vous aidera grandement.

Que sont les permissions ?

Par défaut (en fait c’est selon les plugins mais la plupart des développeurs appliquent cette règle), les commandes du serveur et de ses plugins ne sont accessibles qu’aux operators, ou OP. Ce n’est pas très pratique si on veut personnaliser qui peux faire quoi ; les permissions ont été créées pour palier à ce manque. La plupart des grands serveurs utilisent ce système : il s’agit de classer les personnes du serveur en différents groupes, chaque groupe ayant ses propres permissions ; cela permet de bien définir les droits de chacun et de bien différencier les différents grades dans un serveur (visiteur, joueur, modérateur, administrateur…).

Quel plugin installer ?

De nombreux plugins de permissions existent. Le plus utilisé a longtemps été Permissions (un nom très recherché, vous avez vu ?), créé par TheYeti puis repris par rcjrrjcr depuis sa version 3. Malheureusement, l’équipe de développement du plugin a abandonné le projet ; Permissions est maintenant obsolète, surtout depuis la nouvelle API apportée avec la version 1.1-R5 de Bukkit.

C’est PermissionsBukkit, alors moins connu à l’époque, qui a repris le flambeau. Il s’agit en fait du plugin officiel (mais pas natif) développé par la team de Bukkit, d’où son nom. C’est celui-ci que je choisirais dans ce guide, vous pouvez donc dès maintenant le télécharger et l’installer sur votre serveur à cette adresse.

On peut aussi vous conseiller l’utilisation du plugin LuckPerms, il est de plus en plus utilisé sur les serveurs.

Permissions made easy

Le fonctionnement de PermissionsBukkit est très simple. La base de ce système est les « nodes » ; chaque node correspond à une commande ou fonctionnalité d’un plugin, donnés par le développeur du plugin en question. Chaque utilisateur ou groupe d’utilisateurs possède une liste de nodes, avec la plupart du temps une réflexion simple : vous avez le node vous pouvez le faire, vous n’avez pas le node vous ne pouvez pas le faire. Par exemple, le plugin Essentials possède ce node (pris au hasard dans la liste) :

essentials.time

Ce node correspond, comme vous l’avez sûrement deviné, à la commande /time du plugin, qui permet de voir l’heure d’un monde (à ne pas confondre avec essentials.time.set qui permet de modifier l’heure). Lorsque l’utilisateur envoie cette commande, le plugin regarde si il a le node correspondant et autorise ou non l’exécution de la commande (après, ça dépend encore une fois des plugins).

Après, il vous faudra dire qui peut faire quoi, et je comprends que c’est assez fastidieux de donner chaque node un par un à chaque joueur. C’est pourquoi PermissionsBukkit vous permet de classer les joueurs dans des groupes, et chaque groupe possède ses propres permissions. Comme ça, vous pouvez efficacement paramétrer les permissions de chacun sans se prendre la tête.

Le fichier de configuration

Nous allons maintenant attaquer le plus gros de ce guide : la configuration du plugin. Je vous invite dès maintenant à télécharger Notepad++ si ce n’est pas déjà fait (vivement recommandé) et à ouvrir le fichier config.yml du plugin avec le logiciel que vous venez d’acquérir.

Attention : paramétrez le logiciel pour faire en sorte que la touche de tabulation (TAB) n’ajoute pas le caractère spécial des tabulations mais quatre espaces ! Veillez également à respecter l’indentation (espaces entre le début de la ligne et le texte), le YAML se basant exclusivement sur ça pour détecter la fin de certains éléments !

Vous devriez normalement avoir ceci :

users:
    ConspiracyWizard:
        permissions:
            permissions.example: true
        groups:
        - admin
groups:
    default:
        permissions:
            permissions.build: false
    admin:
        permissions:
            permissions.*: true
        inheritance:
        - user
    user:
        permissions:
            permissions.build: true
        worlds:
            creative:
                coolplugin.item: true
        inheritance:
        - default
messages:
    build: '&cYou do not have permission to build here.'

debug: false

Ne vous en faites pas si vous ne comprenez pas ce qui est écrit, c’est justement le but de ce guide de tout vous expliquer. Le morceau de texte que vous avez ci-dessus est en fait un exemple condensé de tout ce qui est possible de faire à l’aide de ce plugin, à savoir :

  • La liste des utilisateurs (users)
  • Un utilisateur (ConspiracyWizard) avec son groupe (admin) et des permissions individuelles (permissions.example)
  • La liste des groupes (groups)
  • Le groupe par défaut, qui correspond aux visiteurs (default), et un exemple de permission non accordée (permissions.build)
  • Un groupe (admin) avec une « inheritance » (« héritage » en anglais, on verra ça plus tard)
  • Un autre groupe (user) avec une permission normale (permissions.build: true) et d’autres permissions selon les mondes (worlds) et un autre héritage
  • Une des parties configuration du plugin (messages) et une autre (debug)

Commençons dès maintenant, par ordre descendant. Vous pouvez au passage traduire le message « You do not have permission to build here. » par « Vous n’avez pas les permissions pour construire ici. ».

La liste des utilisateurs

Débutée par « users: », la liste des utilisateurs contient tous les utilisateurs présents dans des groupes autres que celui par défaut,et permet de définir des groupes et permissions pour chaque utilisateur. Voici la syntaxe de cette partie :

users: [nom d’utilisateur]: permissions: [node de permission]: [true/false] [node de permission 2]: [true/false] […] groups: – [groupe 1] – [groupe 2] […] [nom d’utilisateur]: permissions: [node de permission]: [true/false] [node de permission 2]: [true/false] […] groups: – [groupe 1] – [groupe 2] […] […]

Voici l’explication complète de tout ce que vous trouverez entre crochets.

  • […] – indique qu’une information peut être dupliquée et répétée
  • permissions – facultatif – la liste des permissions accordées ou non à cet utilisateur
  • [nom d’utilisateur] – mettez le nom de la personne (nom d’utilisateur, pseudo, login…) concernée par les informations qui suivent
  • [node de permission x] – ajoutez ici un node à autoriser ou non
  • [true/false] – mettez « true » pour que le node de gauche soit autorisé à la personne indiquée au dessus ou « false » pour qu’il soit refusé. Notez que la plupart du temps, un node non renseigné dans les permissions sera considéré comme étant refusé ou accessible uniquement aux operators
  • groups – la liste des groupes auquel cet utilisateur appartient
  • [groupe x] – indiquez ici un nom de groupe auquel appartient l’utilisateur spécifié au dessus. Si il se trouve dans plusieurs groupes, il aura les permissions des deux groupes

La liste des groupes

groups: default: permissions: [node de permission]: [true/false] [node de permission 2]: [true/false] […] [groupe 1]: permissions: [node de permission]: [true/false] [node de permission 2]: [true/false] […] worlds: [monde 1]: [node de permission]: [true/false] [node de permission 2]: [true/false] […] [monde 2]: [node de permission]: [true/false] [node de permission 2]: [true/false] […] inheritance: – [groupe 1] – [groupe 2] – […] [groupe 2]: permissions: [node de permission]: [true/false] [node de permission 2]: [true/false] […] worlds: [monde 1]: [node de permission]: [true/false] [node de permission 2]: [true/false] […] [monde 2]: [node de permission]: [true/false] [node de permission 2]: [true/false] […] inheritance: – [groupe 1] – [groupe 2] – […] […]

Ici, ça devient légèrement plus complexe. Tout ce qu’on retrouve au-dessus est la même chose qu’ici, je ne dirai pas certaines informations en double (moi, flemmard ?) :

  • default – il s’agit du groupe par défaut, son nom ne peut pas être changé
  • [groupe x] – le nom du groupe auquel s’appliquent les informations qui suivent
  • worlds – utilisez soit « worlds » soit « permissions » soit les deux. « worlds » permet d’appliquer certaines permissions à certains mondes uniquement
  • [monde x] – le nom du monde auquel les permissions qui suivent appartiennent
  • inheritance – facultatif – vous avez ici le fameux héritage dont nous parlions ci-dessus ; les groupes qui héritent d’autres auront les mêmes permissions que les groupes auxquels ils héritent, en plus de celles habituelles (par exemple, si le groupe « admin » hérite de « user » alors il aura les permissions de « user » en plus de celles habituelles). Cela évite d’avoir à recopier dix mille fois les mêmes permissions pour plusieurs groupes différents qui n’ont que peut de différences
  • [groupe x] (dans l’inheritance) – le nom du groupe dont le groupe actuel hérite

Les commandes et permissions propres au plugin

Heureusement pour nous, le plugin possède des commandes pour gérer la configuration directement en jeu. C’est moins pratique mais peut aider pour promouvoir ou rétrograder un joueur.

Voici la liste complète de toutes les commandes avec les nodes qui vont avec :

  • /permissions reload – permissions.reload – recharge la configuration, plus rapide que /reload mais effectif que sur PermissionsBukkit
  • /permissions check [node] [player] – permissions.check – permet de vérifier si le joueur [player] possède la permission [node]
  • /permissions info [node] – permissions.info – permissions.info – affiche des informations sur le node [node]
  • /permissions dump [player] [page] – permissions.dump – affiche les informations sur le joueur [player] sur plusieurs pages (argument [page])
  • /permissions group – permissions.group.* – liste les commandes associées à la gestion des groupes et donne accès à toutes ces commandes
  • /permissions group list – permissions.group.list – liste les groupes
  • /permissions group players [group] – permissions.group.players – liste les joueurs dans le groupe [group]
  • /permissions group setperm [group] [[world:]node] [true|false] – permissions.group.setperm – ajoute le node [node] dans les permissions du groupe [group] dans le monde [world] (facultatif) avec true ou false
  • /permissions group unsetperm [group] [[world:]node] – permissions.group.unsetperm – effectue le contraire de la commande group setperm ci-dessus
  • /permissions player – permissions.player.* – liste les commandes associées à la gestion des joueurs et donne accès à toutes ces commandes
  • /permissions player groups [player] – permissions.player.groups – liste les groupes du joueur [player]
  • /permissions player setgroup [player] [group] – permissions.player.setgroup – met le joueur [player] dans le groupe [group]
  • /permissions player addgroup [player] [group] – permissions.player.addgroup – ajoute le joueur [player] dans le groupe [group]
  • /permissions player removegroup [player] [group] – permissions.player.removegroup – enlève le joueur [player] du groupe [group]
  • /permissions player setperm [player] [[world:]node] [true|false] – permissions.player.setperm – ajoute le node [node] dans les permissions du joueur [player] dans le monde [world] (facultatif) avec true ou false
  • /permissions player unsetperm [player] [[world:]node] – permissions.player.unsetperm – effectue le contraire de la commande player setperm ci-dessus

Il y a également le node permissions.build qui autorise ou non la construction (pour empêcher les visiteurs de casser des blocs par exemple) ainsi que permissions.* qui donne accès à toutes les fonctionnalités du plugin.

Pour les développeurs

L’utilisation des permissions dans le développement de plugins est très simple. Tout d’abord, vous devez ajouter ces lignes dans le fichier plugin.yml de votre plugin :

permissions: [node 1]: description: [description] default: [true/false/op/not op] [node 2]: description: [description] default: [true/false/op/not op] […]

Voici quelques explications :

  • [node x] – le node auquel s’appliquent les informations qui suivent
  • [description] – la description de ce node
  • [default] – si la permission n’est pas spécifiée dans la configuration de PermissionsBukkit, elle est soit accordée (true), refusée (false), accordée uniquement aux operators (op) ou aux non-operators (not op)

Pour savoir si un joueur possède une permission ou non, il faut utiliser (en considérant player comme étant une variable de type Player non nulle et [node] la permission en question) :

if (player.hasPermission("[node]")
  {
     //Si le joueur a la permission, on effectue quelque chose
  }
else
  {
    //Sinon on fait autre chose
  }

Les préfixes dans le chat

L’intérêt des permissions est de pouvoir personnaliser le chat en y rajoutant des préfixes et suffixes. Voici un exemple :

On peut voir ici que des préfixes en couleur ont été rajoutés avant le nom du joueur, contenant le monde dans lequel le joueur se trouve ainsi que le groupe auquel il appartient. Mais alors, comment faire ça ? Vous devez utiliser le plugin Simple Prefix, que je vous invite à télécharger et installer sur votre serveur dès maintenant.

Voici la configuration par défaut du plugin :

Template:
  format: '[time] [world] [prefix][name][suffix] '
  time: '[h:mm aa]'
Worlds:
  world:
    nickname: '&e[World]&f'
Group:
  example:
    prefix: '&a[Example]&f'
    suffix: ''
User:
  Flabaliki:
    prefix: '&c[Who?]&f'
    suffix: ''

Voici une explication rapide de cette configuration :

  • format – il s’agit du schéma d’un message, vous pouvez y mettre ce que vous voulez avec les couleurs que vous voulez. Vous pouvez afficher des valeurs spéciales comme le temps avec [time], le monde avec [world], le préfixe avec [prefix], le nom de la personne avec [name] et le suffixe avec [suffix]
  • time – il s’agit du format d’affichage du temps (balise [time])
  • Worlds – vous pouvez déterminer ici les pseudos qu’auront vos mondes. C’est ce texte qui sera affiché à la place du nom classique du monde, pratique lorsque vous avez un monde avec un nom peu adapté (comme par exemple world)
  • Group – et oui, vous devez retranscrire vos groupes ici ! Chaque groupe possède un préfixe et suffixe qui lui est propre
  • User – si vous ne souhaitez pas utiliser le système de permissions pour déterminer qui est dans chaque groupe (ce que nous allons faire), vous pouvez utiliser cette fonctionnalité

Voici maintenant la configuration type du plugin, pour utiliser avec PermissionsBukkit :

Template: format: ‘[time] [world] [prefix][name][suffix] ‘ time: ‘[h:mm aa]’ Worlds: world: nickname: ‘&e[World]&f’ Group: example: prefix: ‘&a[Example]&f’ suffix:  » User: Flabaliki: prefix: ‘&c[Who?]&f’ suffix:  »

Et les explications qui vont bien :

  • [monde x] – le nom du monde dont vous voulez personnaliser le nom
  • [pseudo] – le nom que vous voulez donner à ce monde
  • [groupe x] – le nom du groupe à personnaliser le préfixe et suffixe, ce ne sont pas nécessairement les même groupes que ceux de PermissionsBukkit
  • [préfixe] – le préfixe à mettre pour ce groupe
  • [suffixe] – le suffixe à mettre pour ce groupe

Une fois cela défini, il faut indiquer au plugin quel groupe de PermissionsBukkit correspond à quel groupe de Simple Prefix. Pour ce faire, ajoutez au groupe de votre choix la permission simpleprefix.[groupe], où [groupe] est le groupe correspondant dans Simple Prefix. Par exemple, le groupe « default » aura la permission simpleprefix.visiteur car le groupe dans la configuration de Simple Prefix s’appelle « visiteur ».

Pour conclure

Pour conclure, nous pouvons dire que PermissionsBukkit est un plugin compliqué d’utilisation, mais une fois qu’on le maîtrise, on peut faire de grandes choses avec ;).