Gérer les clés et droits d'accès API
Une clé API accorde à une application externe l'accès à votre compte edoobox. Ses capacités correspondent au droit qui lui est attribué. Traitez-la donc avec le même soin qu'un accès administrateur et créez une clé distincte pour chaque usage.
Un nouvel accès se compose d'une clé publique et d'une clé secrète. La clé secrète n'est affichée qu'une seule fois après la création. Sans clé secrète stockée en toute sécurité, le même accès ne peut pas être entièrement reconstitué ultérieurement.
Définir à l'avance l'usage et le droit
Documentez avant la création l'application, la personne responsable, l'environnement et les actions requises. Un simple export n'a pas besoin de droit d'écriture ; une intégration WordPress ou une automatisation Zapier doit recevoir le droit qui lui est destiné.
L'interface V2 propose les droits individuels existants et, s'ils ne sont pas encore configurés, des options préparées pour le droit de lecture, le droit WordPress et le droit Zapier. Lors d'une telle sélection, edoobox crée le droit approprié et l'associe à la clé.
Créer une clé
En tant que Superadmin, ouvrez Paramètres → Gestion des accès API et sélectionnez Ajouter une clé.
Décidez si l'accès doit être immédiatement actif et sélectionnez exactement un droit.
Confirmez avec Ajouter. Copiez immédiatement la clé publique et la clé secrète dans le gestionnaire de secrets ou de mots de passe prévu à cet effet.
Ne fermez la fenêtre de dialogue qu'après avoir vérifié le stockage sécurisé. N'envoyez pas la clé secrète par e-mail ou chat sans chiffrement.
Contrôler les accès existants
Le tableau API permet de copier la clé publique et d’activer ou de désactiver un accès. Si le droit initialement attribué a été supprimé, le tableau indique aucun droit attribué. Cette clé n’est alors pas utilisable correctement ; n’attribuez pas un autre droit sans vérifier l’usage prévu de l’intégration.
Effectuez un contrôle au moins trimestriellement :
L'application est-elle encore utilisée et une personne responsable est-elle connue ?
Le droit correspond-il toujours à l'accès réel aux données ?
La clé appartient-elle au bon environnement, par exemple test ou production ?
Y a-t-il des accès obsolètes, en double ou non documentés ?
Renouveler les clés sans interruption inutile
Créez une nouvelle clé avec le même droit minimal et stockez la nouvelle clé secrète en toute sécurité.
Enregistrez la clé publique et la clé secrète dans le système cible et testez une requête en lecture ou sans risque.
Observez le flux de production. Désactivez ensuite l'ancienne clé.
Mettez à jour votre documentation interne avec la date et la personne responsable.
Identifier systématiquement les erreurs
| Symptôme | Vérification |
|---|---|
| L'authentification échoue | Vérifiez la clé publique et la clé secrète, les valeurs inversées, les espaces, l'environnement et le statut actif. |
| Accès refusé | Comparez le droit attribué à la ressource nécessaire ; vérifiez si le tableau indique aucun droit attribué. |
| La lecture fonctionne, l'écriture non | Le droit de lecture est volontairement limité. Ne créez un droit d’écriture restreint que si le besoin fonctionnel le justifie. |
| L'intégration s'arrête après le changement | Vérifiez si les deux nouvelles valeurs de clé sont enregistrées dans le système cible et si ses processus ont été rechargés. |
Exemples d'application
Exemple d'application : Rapportage en lecture seule
Un tableau de bord interne lit les offres et les réservations, mais ne modifie aucune donnée. Il reçoit à cet effet une clé active distincte avec droit de lecture. La clé est documentée séparément de WordPress et Zapier et peut être désactivée indépendamment.
Exemple d'application : Séparer WordPress et Zapier
Le site utilise une clé disposant du droit WordPress, tandis qu’une automatisation de facturation utilise une deuxième clé disposant du droit Zapier. Si l’automatisation n’est plus utilisée, vous pouvez désactiver sa clé sans interrompre l’intégration du site.
Exemple d'application : Soupçon de divulgation de la clé secrète
Une clé secrète était accidentellement visible dans une note interne. L’équipe désactive immédiatement l’accès concerné, crée une clé de remplacement et l’enregistre de manière sûre dans le système cible. Elle teste ensuite la connexion et vérifie les traitements en échec ou en attente avant de les relancer de manière contrôlée. L’ancienne clé secrète n’est plus utilisée.
Coordonner le profil de droits avec l'exploitation
Pour créer une clé, vous devez disposer des droits de superadministrateur et accéder à Paramètres → Gestion des accès API. La fenêtre contient le statut et la sélection des droits. Elle ne propose pas de champ pour nommer la clé ; consignez donc son usage, la personne responsable et l’environnement dans votre liste interne des accès, en vous basant sur la clé publique.
Pour les clés existantes, la vue d'ensemble affiche le statut, la clé publique et le profil de droits associé. Vérifiez le contenu de ce profil via le lien. Si l'étendue ou l'usage doit être modifié de manière significative, créez un accès distinct avec le droit prévu et effectuez la migration de manière contrôlée.