Permissions et sécurité

But : décider qui voit et qui peut utiliser chaque option, en sachant ce qui est vraiment contrôlé par le serveur. Fichiers : config.lua (AdminGroups, ModGroups, UseAcePermissions, Permissions) et server.cfg pour les ACE.

Les niveaux

L’appartenance à un groupe est vérifiée par Bridge.HasGroup :

• ESX : xPlayer.getGroup() doit être exactement égal au nom du groupe. Un joueur superadmin n’est pas admin : listez les deux si besoin.
• QBCore : QBCore.Functions.HasPermission, puis l’ACE group.<nom>.
• Autres (qbx, ox, nd, standalone) : IsPlayerAceAllowed(source, 'group.<nom>'). Si ce test échoue chez vous, accordez explicitement cette ACE au groupe, par exemple add_ace group.admin group.admin allow.
• Le hook serveur HasGroup(source, group) remplace tout ce qui précède.

Les clés

Vous pouvez ajouter vos propres clés et les utiliser dans le champ permission d’une option ou d’une action serveur :

Config.Permissions = {
    staffMenu   = 'staff',
    revive      = 'admin',
    heal        = 'admin',
    selfRevive  = 'staff',
    selfHeal    = 'staff',
    forceEmote  = 'admin',
    forceMe     = 'admin',
    weather     = 'admin',
    giveKeys    = 'admin',
    devTools    = 'admin',
    emsTools    = { 'ambulance_chef', 'admin' },
}

Ne supprimez pas les dix clés d’origine : un builtin dont la clé manque devient invisible et refusé pour tout le monde.

ACE

Avec Config.UseAcePermissions = true, l’ACE ox_target.<clé> accorde la permission avant le contrôle des groupes :

add_ace group.helper ox_target.selfHeal allow
add_ace identifier.license:0123456789abcdef ox_target.devTools allow

La vérification ACE se répète à chaque étape d’un renvoi : pour selfHeal = 'staff', l’ACE ox_target.selfHeal suffit, mais aussi ox_target.staff, qui ouvre alors toutes les clés valant 'staff'. L’ACE ne remplace pas la clé : retirer selfHeal de Config.Permissions rend l’option invisible même avec l’ACE.

Ce que fait le client

Le client reçoit du serveur une carte des permissions : chaque clé de Config.Permissions, les niveaux everyone, staff, admin, et pour chaque action serveur personnalisée son résultat. Il la redemande toutes les Config.Security.permissionRefresh ms et après le chargement du personnage. Cette carte sert uniquement à masquer des options.

Conséquences :

• Une option avec une permission inconnue de la carte est toujours masquée.
• Un changement de groupe en jeu peut mettre jusqu’à permissionRefresh ms à se refléter dans le menu.
• Les champs jobs, groups et items d’une option sont évalués côté client pour l’affichage.

Ce que vérifie le serveur

Les builtins qui passent par une action serveur et vos server_action sont contrôlés par le moteur, dans cet ordre : action connue, anti-spam, fonctionnalité, disponibilité de l’intégration, permission, métier, arguments, existence de la cible et distance (+ distanceTolerance), item. Une requête refusée de façon anormale est signalée (OnSuspiciousActivity ou console).

Options sans contrôle serveur dans l’archive : copier/voir l’ID, saisie de /me, anti-punch, outils de copie des Dev Tools, « Prendre apparence », restauration d’apparence, outils météo locaux et facture (validée par le script de facturation). Le défi Pierre Feuille Ciseaux et la cachette dans le coffre ont leurs propres contrôles serveur (distance, disponibilité).

Erreurs fréquentes

• Option staff visible pour tout le monde : la catégorie a permission = 'staffMenu' mais une option enfant a été déplacée hors du sous-menu sans permission.
• 'superadmin' refusé sous ESX : ajoutez-le à Config.AdminGroups.
• ACE sans effet : Config.UseAcePermissions est resté à false.