Token GitHub App più lunghi: rivedere l’ipotesi dei 40 caratteri
Se falliscono solo i token nuovi, segui il percorso della stringa prima di ampliare i permessi. L’emissione riuscita non prova che database o proxy ne conservino il valore.
Il 2 ottobre 2026 GitHub ha annunciato il completamento del rollout stateless dei token di installazione App. ghs_APPID_JWT mantiene ghs_ ma passa da 40 a circa 520 caratteri; non è una regola per tutti i token personali.
Distinguere formato e accesso
Permessi, ambito dei repository, scadenza di un’ora ed endpoint REST restano invariati. Più privilegi non risolvono una stringa troncata; separa emissione e utilizzo.
L’header temporaneo X-GitHub-Stateless-S2S-Token sarà ritirato il 30 novembre 2026. Verifica entrambi i formati e rimuovilo prima, indicando responsabile e scadenza.
Conservare la stringa intera
Tratta il token come stringa opaca. Cerca validatori da 40 caratteri, colonne piccole, limiti dei secret store e rifiuti degli header Authorization lunghi.
Prova prima con valori sintetici e registra solo lunghezze ed esito. Non trasformare 520 in un nuovo limite rigido; verifica i vincoli documentati lungo il percorso.
Controllare anche i log di errore
Un mascheramento pensato per il formato precedente può lasciare parti visibili. Usa dati sintetici per verificare rifiuti, tentativi ripetuti ed eccezioni.
La guida GitHub comprende minimo privilegio, mascheramento e controllo dei log. Suggeriamo una revisione comune tra responsabili di storage e logging; l’autenticazione riuscita non basta.
Provare in piccolo e segnare la scadenza
La domanda pratica è se la stringa arriva integra dall’inizio alla fine. È un’inferenza dall’avviso ufficiale, non una presunta opinione della comunità.
Fuori produzione, completa test sintetici, chiamata con privilegi minimi e verifica dei log prima di estendere. È un nostro suggerimento operativo. Registra punto di errore, responsabile e scadenza dell’header.