GitHub App-tokens er blevet længere: Kontrollér integrationernes antagelser
GitHub meddelte den 2. oktober 2026, at udrulningen af det nye stateless-format til App-installationstokens er afsluttet. Ændringen er relevant for teams, som har egne integrationer eller mellemled omkring GitHub-adgang.
Længden ændres, adgangens omfang gør ikke
Nye tokens er omkring 520 tegn mod tidligere 40 og beholder ghs_-præfikset. GitHub angiver uændrede rettigheder, repository-afgrænsning og udløb efter en time. Eksisterende tokens virker frem til deres udløb.
Den midlertidige X-GitHub-Stateless-S2S-Token-header udfases 30. november 2026. GitHub anbefaler at behandle tokens som uigennemsigtige tekstværdier og kontrollere længdekrav, afkortning og regler, der skjuler hemmeligheder i logs.
Undersøg hele vejen gennem integrationen
Min anbefaling er at identificere, hvor adgangsværdien modtages, opbevares og sendes videre. En klient kan understøtte den nye længde, mens et mellemled stadig antager et kortere format.
Et tænkt eksempel er en indstillingsformular med et historisk maksimum. Værdien kan se korrekt ud ved oprettelsen, men blive afkortet ved lagring. Kontrollen bør derfor følge hele forløbet.
Undgå at gøre format til identitet
En lokal kontrol, der kun accepterer en bestemt længde, kan afvise en gyldig adgangsværdi. Omvendt dokumenterer en passende længde ikke, at værdien giver adgang til den rigtige ressource.
Skeln mellem, om integrationen bevarer værdien korrekt, og om den valgte identitet har den nødvendige adgang. Det er to forskellige spørgsmål, som bør have hver sin kontrol.
Test uden at udstille hemmeligheder
Brug syntetiske værdier til at undersøge lagring og afkortning. Den konkrete adgang kan derefter kontrolleres med et lille, relevant læsekald gennem den normalt konfigurerede integration.
Udskriv ikke rigtige tokens for at sammenligne dem. Denne artikel indeholder ingen egen integrationstest; den peger på de antagelser, som GitHubs formatændring gør relevante at gennemgå.