Token przechodzi przez bibliotekę, magazyn sekretów, proxy i reguły maskowania logów. Każdy z tych elementów może mieć własny pomysł na jego długość. Dostawca zmienia format, a nasza integracja odkrywa, że „ciąg znaków” jednak miał ukryty kontrakt.
Co potwierdził GitHub
Data wydarzenia: 2 października 2026. GitHub ogłosił zakończenie wdrażania bezstanowych tokenów instalacyjnych GitHub Apps. Nowe tokeny zachowują prefiks ghs_, ale mają około 520 znaków zamiast 40. Uprawnienia, zakres repozytoriów i godzinny czas ważności pozostają bez zmian. Tymczasowy nagłówek X-GitHub-Stateless-S2S-Token zostanie wycofany 30 listopada 2026.
Źródło opisuje zmianę produktu. Nie jest raportem awarii konkretnej integracji. „Około 520” nie oznacza nowego stałego limitu, który należy wpisać do walidatora.
Co z tego wynika dla architektury
Interpretacja ArchitectMentor: integracja powinna przekazywać token bez uzależniania działania od jego wewnętrznej struktury. To poświadczenie dla API dostawcy, a nie nasz model danych. Dla samego przekazywania nie potrzebujemy rozkodowywania jego części ani własnej walidacji podpisu. Odpowiedź serwera rozstrzyga o przyjęciu poświadczenia; lokalna kontrola długości tego nie zastąpi.
Nie oznacza to zniesienia wszystkich limitów. Limity nagłówków i magazynów nadal są potrzebne. Trzeba dobrać je do obsługiwanych poświadczeń, udokumentować i sprawdzić, a nie odziedziczyć z przykładu sprzed kilku lat. Większy token nie jest też powodem do nadania większych uprawnień.
Sprawdź cztery miejsca
| Miejsce | Co może zawieść | Jak sprawdzić |
|---|---|---|
| Walidacja i biblioteki | Warunek dokładnie 40 znaków lub wzorzec starego formatu. | Test przekazania dłuższej wartości bez zmiany jej treści; następnie test nowego tokenu przez API. |
| Magazyn sekretów i baza | Ciche obcięcie, zbyt mała kolumna albo limit pola. | Zapis i odczyt sztucznego ciągu o reprezentatywnej długości; porównanie wartości w pamięci, bez wypisywania jej. |
| Proxy i brama | Odrzucenie lub obcięcie nagłówka Authorization. | Przejście przez rzeczywistą trasę żądania, z kontrolą odpowiedzi na każdym etapie. |
| Logi i telemetryka | Maskowanie rozpoznaje wyłącznie stary wzorzec. | Sztuczny znacznik przypominający nowy format nie może pojawić się w żadnym zebranym logu. |
Dwa testy, dwie różne odpowiedzi
Fikcyjny przykład edukacyjny: worker budujący dokumentację pobiera token, zapisuje go w magazynie i wywołuje API przez firmowe proxy. Test z długim sztucznym ciągiem może wykazać, że transport i zapis nie obcinają wartości. Nie udowodni jednak, że GitHub zaakceptuje poświadczenie.
Dlatego drugi test wykonaj na instalacji testowej z minimalnym zakresem i świeżo wystawionym tokenem: wywołaj dozwoloną operację odczytu przez tę samą trasę. Jeśli pojawi się błąd, rozdziel problem formatu od uprawnień, wygaśnięcia i konfiguracji instalacji. Nie drukuj pełnego nagłówka, aby „zobaczyć, co naprawdę wysłano”. To wygodny sposób na stworzenie kolejnego problemu.
Sprawdź również pobranie nowego tokenu po wygaśnięciu poprzedniego. Samo jednorazowe powodzenie z wartością trzymaną w cache nie potwierdza działania odnowienia.
Decyzja i granice
Najpierw usuń zależności od starej długości i potwierdź zapis, transport, maskowanie oraz odnowienie. Dopiero po kontroli integracji usuń tymczasowy nagłówek przed terminem wycofania. Jeżeli token mógł trafić do logów, ogranicz dostęp do nich, unieważnij ujawnione poświadczenie zgodnie z procedurą dostawcy i zbadaj zakres ujawnienia.
Ta wiadomość dotyczy tokenów instalacyjnych GitHub Apps w GitHub Enterprise Cloud i środowiskach Data Residency; wcześniejsza dokumentacja zakresu wyłącza GitHub Enterprise Server. Nie wynika z niej, że wszystkie PAT, tokeny OAuth czy lokalne JWT zmieniły format. Nie ma też podstaw, by deklarować awarię którejkolwiek organizacji.
Ucz się: jak sprawdzać zgodność zmiany kontraktu API →
Porozmawiajmy o tym artykule
Podziel się uwagą lub zanonimizowanym przykładem. Komentarze sprawdza AI przed publikacją. Niejednoznaczne przypadki trafiają do moderatora.