Tokens GitHub App plus longs : vérifier l’hypothèse des 40 caractères
Si seuls les nouveaux tokens échouent, inspectez leur parcours avant d’élargir les permissions. Une émission réussie ne garantit pas que la base ou le proxy conserve toute la chaîne.
GitHub a annoncé le 2 octobre 2026 la fin du déploiement stateless des tokens d’installation d’Apps. Le format ghs_APPID_JWT conserve ghs_ mais passe de 40 à environ 520 caractères. Cela ne définit pas tous les tokens personnels.
Distinguer format et accès
Permissions, périmètre des dépôts, expiration d’une heure et endpoint REST restent inchangés. Ajouter des droits ne corrige pas une troncature; séparez émission et utilisation.
Le header temporaire X-GitHub-Stateless-S2S-Token sera retiré le 30 novembre 2026. Vérifiez les deux formats puis retirez-le avant cette date, avec un responsable identifié.
Préserver toute la chaîne
Traitez le token comme une chaîne opaque. Cherchez les validateurs de 40 caractères, petites colonnes, limites des coffres et rejets de longs headers Authorization.
Testez d’abord avec des valeurs synthétiques et ne journalisez que longueurs et résultats. Ne remplacez pas l’ancien seuil par un plafond rigide de 520; vérifiez les contraintes documentées.
Vérifier aussi les erreurs
Un masque conçu pour l’ancien format peut dévoiler une partie du nouveau. Contrôlez refus, tentatives répétées et exceptions avec des données synthétiques.
Les conseils de sécurité GitHub couvrent privilège minimal, masquage et contrôle des logs. Notre proposition est une revue commune du stockage et des logs; une authentification réussie ne suffit pas.
Tester petit et noter l’échéance
La question utile est la préservation de la chaîne de bout en bout. C’est une déduction du communiqué officiel, pas une prétendue opinion dominante de la communauté.
Hors production, terminez tests synthétiques, appel à privilège minimal et revue des logs avant d’élargir. Cet ordre est notre recommandation. Notez frontière défaillante, responsable et échéance du header.