« Un seul jeton pour tout »
Quand vous installez plusieurs modules Guestrezlynx ou plusieurs autres extensions tierces D-EDGE, la tentation est forte de créer un seul jeton API avec un scope large et de le partager entre toutes les extensions. C’est rapide, ça marche, et ça vous évite de gérer 5 jetons différents.
Nous vous recommandons de ne pas faire ça. Voici trois raisons.
Qui a fait quoi ?
Quand un jeton unique est partagé entre 5 modules, tous les appels API D-EDGE apparaissent dans les logs D-EDGE avec le même identifiant de jeton. Si un module se met à faire une opération inattendue (ex : push tarif divisé par 2 pour une date par erreur), impossible de savoir lequel des 5 modules est responsable sans instrumentation externe.
Un jeton par module = un identifiant par module dans les logs D-EDGE = enquête possible en 5 minutes.
Couper un module sans couper les autres
Vous décidez d’arrêter la Passerelle POS parce que vous changez de POS Restauration. Avec un jeton unique, révoquer le jeton coupe aussi l’Autopricer et le Pont Sage. Avec des jetons séparés, vous ne coupez que le module concerné.
Le principe du moindre privilège
Chaque module Guestrezlynx a besoin d’un scope différent : le Wi-Fi invité a besoin de read reservations uniquement, l’Autopricer a besoin de read + write rates. Un jeton par module = scope adapté à chaque module = surface d’attaque minimale en cas de compromission.
Notre onboarding vous précise systématiquement le scope minimum requis pour chaque module Guestrezlynx.