Aller au contenu

API et sécurité

Les routes immobilières internes dérivent personnage et position sur FXServer, puis l'API revalide proximité et routing bucket. Les codes échouent fermés sans Redis et ne figurent jamais dans les audits. Voir Architecture technique de l'immobilier.

Surfaces HTTP

  • système : GET /health, /ready, /version ;
  • public : GET /public/loading-screen ;
  • admin : OAuth, session, whitelist, loading screen, permissions, personnages, modération et logs sous /admin ;
  • interne : joueurs, personnages, Discord, modération et autorisations sous /internal/v1.

Les routes internes exigent X-Internal-Api-Key. Les mutations Discord passent par le bot avec un secret distinct BOT_INTERNAL_API_KEY, qui n'est pas transmis à FiveM.

Authentification admin

Le navigateur démarre OAuth2 auprès de Discord. L'API orchestre le callback via le service privé du bot, construit une session serveur et pose un cookie. En HTTPS, ADMIN_COOKIE_SECURE=true est obligatoire. L'URL DISCORD_OAUTH_REDIRECT_URI doit correspondre exactement à celle enregistrée dans le portail Discord.

Autorisation

Le moteur central calcule rang, grants directs et héritage. Founder reçoit systématiquement ALL_PERMISSIONS. Les actions sensibles vérifient la permission, le rang de l'acteur et, pour un grant, que l'acteur possède lui-même la permission concernée.

ADMIN_ALLOW_TPM, ADMIN_ALLOW_TPC et ADMIN_ALLOW_DELETE_VEHICLE appartiennent au catalogue partagé et protègent respectivement /tpm, /tpc et /delv. Comme les autres permissions, elles sont incluses automatiquement dans ALL_PERMISSIONS pour Founder et doivent être accordées explicitement aux autres rôles.

Les consommateurs non web utilisent :

POST /internal/v1/admin/authorize
POST /internal/v1/admin/authorize-role-action

Toute action admin est associée à l'identité Discord de l'acteur dans l'audit. Les secrets ressemblant à des tokens ou mots de passe sont masqués dans les réponses de journaux. GET /admin/audit-logs filtre en base par actor et action. Le paramètre search de GET /admin/system/logs/{application} filtre sans tenir compte de la casse pendant la lecture des fichiers, avant l'application de la limite, sans accepter d'expression régulière côté serveur.

Les routes /internal/v1/vehicles/* exigent également la clé interne et le feature flag. Toute action reçue de FiveM revalide côté serveur l'identité du personnage, l'entité réseau, le bucket, la distance et la clé stockée. Une plaque, un network ID, une metadata d'item ou un state bag fourni par le client ne constitue jamais une autorisation.

Routes énergie

/internal/v1/vehicle-energy/* exige la clé interne ; /admin/vehicle-energy/* cumule OAuth, permission et CSRF. Entité, bucket, distance, séquence, clé, compatibilité, coût et niveau sont revalidés côté serveur. Une pompe est revendiquée par modèle allowlisté, position quantifiée, station et bucket ; le serveur reconstruit connector_key et refuse tout descripteur falsifié avant réservation. Les observations client sont bornées à 32 clés et 16 observateurs, horodatées côté serveur et ne constituent jamais seules une autorisation de paiement.

Les mutations actives acceptent les propulsions gasoline|diesel|electric, les unités liter|percent et uniquement leur produit compatible : Regular/Plus/Premium pour l'Essence, Diesel pour le Diesel, Charge normale/rapide pour l'Électrique. La catégorie physique Route/Aviation/Maritime est revalidée par l'API avant toute réservation. Les archives refusent toute mutation côté service, indépendamment de l'interface. Voir Énergie des véhicules.