GitHub App Installation Token'ları Artık 520 Karakter

⏱️ 3 dk okuma📅 3 Ekim 2026

GitHub App kurulum token’larında kullanılan yeni stateless biçimin kademeli dağıtımı tamamlandı. Bundan sonra üretilen tüm GitHub App installation token’ları varsayılan olarak ghs_APPID_JWT formatında geliyor. En görünür fark uzunlukta: token’lar eskiden yaklaşık 40 karakterdi, artık yaklaşık 520 karakter. Aşağıdaki özet, kaynak duyurudaki bilgilerle sınırlı.

Değişen ne, değişmeyen ne?

GitHub’ın duyurusuna göre 27 Nisan 2026’da başlayan kademeli dağıtım süreci tamamlandı, yeni üretilen bütün installation token’ları artık stateless biçimde veriliyor. GitHub değişikliğin gerekçesini iki başlıkta topluyor: token üretimi ile doğrulamasının hızlanması ve GitHub API’nin güvenilirliğinin artması. Stateless yapının mantığı adından anlaşılıyor, token’ın geçerliliğini doğrulamak için merkezi bir durum kaydına bakma ihtiyacı azalıyor, bilgi token’ın kendisinde taşınıyor.

Değişenler kısmı oldukça dar:

Installation token’ları hala ghs_ ön ekiyle başlıyor.
Uzunluk 40 karakterden yaklaşık 520 karaktere çıktı.

Değişmeyenler listesi ise beklediğinizden uzun olabilir:

Token izinleri (permissions) aynı şekilde çalışıyor.
Repository kapsamlandırması (repository scoping) değişmedi.
Bir saatlik geçerlilik süresi korunuyor.
Installation access token REST API uç noktası aynı kaldı.

Değişiklikten önce üretilmiş token’lar da süreleri dolana kadar çalışmaya devam ediyor. Geçişte ani bir kesinti senaryosu tanımlanmış değil, mevcut token’lar normal yaşam döngüsünü tamamlıyor.

Geçici doğrulama başlığı ve takvimi

GitHub, geliştiricilerin yeni biçimi istedikleri anda test edebilmesi için geçici bir istek başlığı sunmuştu: X-GitHub-Stateless-S2S-Token. Bu başlık sayesinde uygulamalar, genel dağıtım tamamlanmadan önce stateless token’larla kendi akışlarını deneyebiliyordu.

Duyuruya göre bu geçici başlık 30 Kasım 2026 tarihinde kullanımdan kaldırılacak. O tarihten sonra GitHub başlığı dikkate almayacak, uygun tüm uygulamalar her durumda stateless token alacak. Yapılacak iş de net, her iki token biçimiyle uygulamalarınızı ve iş akışlarınızı doğruladıktan sonra başlığı 30 Kasım 2026’dan önce üretim kodunuzdan çıkarın.

Dikkat edilmesi gereken ayrıntı, başlığın kaldırılmasının davranışsal bir kesinti yaratmaması, ancak kodda gereksiz bir bağımlılık olarak sürmesi. Başlığı temizlemek, ileride “neden bu başlık gönderiliyor?” sorusunu soracak ekipler için de teknik borç azaltıyor.

Entegrasyonlarınızda kontrol edilecek noktalar

Kaynak duyurunun en işe yarar bölümü, uzunluk değişiminin nerelerde patlayabileceğini listeleyen kısım. Temel ilke, installation token’larını opak (opaque) birer dize olarak ele almak; yani içeriğini ayrıştırmaya, uzunluğuna göre doğrulamaya veya belirli bir desene uymasını beklemeye çalışmayın.

GitHub’ın işaret ettiği riskli alanlar:

Doğrulama kuralları: Token’ın tam olarak 40 karakter olmasını şart koşan kontroller ya da eski biçime göre yazılmış desenler (regex vb.) yeni token’ları doğrudan reddeder.
Depolama alanları: Veritabanı sütunları, secret store kayıtları veya ortam değişkenleri için tanımlanmış sabit ya da düşük maksimum uzunluklar. 40 karaktere göre boyutlandırılmış bir alan, 520 karakterlik bir değeri ya kırpar ya hata verir.
Ağ katmanı: Uzun Authorization başlıklarını kısaltan veya reddeden proxy’ler, gateway’ler ve middleware bileşenleri. Teşhisi en zor hata sınıflarından biri olabilir, çünkü sorun uygulama kodunda değil araya giren katmanda ortaya çıkar.
Loglama ve gizleme kuralları: Yalnızca eski token desenine uyan secret redaction (gizli bilgi maskeleme) kuralları. Kural eşleşmezse token log kayıtlarına açık biçimde düşebilir, güvenlik açısından kritik olan nokta da bu.

Son madde ayrıca önemli. Doğrulama veya depolama kaynaklı hatalar genelde gürültülü biçimde fark edilir, maskeleme kuralının eşleşmemesi ise sessizce çalışır ve ancak log’lara bakıldığında anlaşılır. Token biçimi değiştiyse gizleme kurallarının da yeni biçimi kapsadığını doğrulamak gerekiyor.

Pratik bir kontrol listesi

Duyurudaki bilgileri uygulanabilir bir sıraya koyarsak:

Installation token’larını kullanan tüm sistemleri çıkarın: uygulama kodu, CI/CD iş akışları, yardımcı servisler, script’ler.
Token’ı sabit uzunlukla doğrulayan veya eski desene göre ayrıştıran her yeri bulup kaldırın.
Token’ı saklayan alanların en az 520 karakterlik bir değeri sorunsuz tutabildiğini doğrulayın.
Araya giren proxy/gateway katmanlarında Authorization başlığı için uzunluk sınırı olup olmadığını kontrol edin.
Log maskeleme kurallarının yeni ghs_APPID_JWT biçimini de kapsadığını test edin.
Her iki biçimle doğrulama tamamlandıysa X-GitHub-Stateless-S2S-Token başlığını üretim kodundan çıkarın.

Kurulum token’larının nasıl üretildiği ve kullanıldığı konusunda ayrıntılı bilgi için GitHub’ın resmi dokümantasyonu başvurulacak doğru kaynak. Çok sayıda uygulamayı yöneten ekipler için bu geçiş, token ele alma biçimini bir kez elden geçirip opak dize ilkesine kalıcı olarak uyumlanma fırsatı da sunuyor.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102