Apple, app-specific-password ile yapılan IPA yüklemelerini engelledi: Windows ve Linux CI hataları kırıldı

dev.to'da yayımlanan ayrıntılı bir yazıya göre, Apple ID ve app-specific password ile kimlik doğrulayan IPA yükleme araçları 28 Ekim civarında çalışmamaya başladı. Bu değişiklik, ios-uploader gibi araçlarla veya özel betiklerle build'leri gönderen Windows ve Linux CI hatlarını kırarken, Xcode ve Apple'ın resmi Transporter uygulaması normal çalışmaya devam ediyor.

Ne bozuldu

dev.to yazısına göre, Apple ID ve app-specific password ile kimlik doğrulayan yükleme araçları artık giriş adımında başarısız oluyor. İstemcinin beklediği JSON yanıtı yerine, Apple'ın yükleme kimlik doğrulama endpoint'i, kullanıcının oluşturduğu app-specific password ile oturum açmasını isteyen düz metin döndürüyor ve yanıt -22938 hata koduyla bitiyor. Yanıtı JSON olarak ayrıştıran betikler genellikle 'Unexpected token S' gibi bir parse hatasıyla çöküyor; bu da sorunun Apple tarafındaki bir değişiklik değil, istemci taraflı bir hata gibi görünmesine yol açıyor.

Sorun kimlik bilgilerinde değil

Yazının yazarı, aynı app-specific password'un Apple'ın CalDAV endpoint'inde hâlâ kimlik doğruladığını ve HTTP 207 yanıtı aldığını doğruladı. Bu da kimlik bilgilerinin süresinin dolduğunu veya yanlış yazıldığını dışlayarak sorunun doğrudan yükleme servisine işaret ediyor.

Uzun bir dizi deneme, sorunu daha da daralttı. Düz ve gzip ile sıkıştırılmış istek gövdeleri, HTTP/1.1 ve HTTP/2, JSON-RPC endpoint'i, SOAP endpoint'i, iTMSTransporter 4.2.0 ve 4.3.1 ile Transporter 5.0'ı taklit eden User-Agent dizileri, myacinfo çerezi ya da Bearer token olarak gönderilen bir App Store Connect API anahtarı JWT'si ve alternatif bir içerik dağıtım sunucusu — hepsi aynı oturum açma istemiyle sonuçlandı. Bilerek var olmayan bir JSON-RPC metot adı bile aynı mesajı döndürdü; yani istekler backend servisine ulaşmadan ağ geçidinde reddediliyor. Yanıt başlıklarında Server: daiquiri/5 ve 26HOTFIX47 instance etiketi görülüyor.

Yazıdaki sonuç şudur: Apple, Apple-ID-artı-app-specific-password giriş yolunu ağ geçidinde kapattı ve istemci tarafında yapılacak hiçbir parametre değişikliği bunu geri getirmeyecek.

Yerine gelen: Build Uploads API

Önerilen çözüm, bir API anahtarı (JWT) ile kimlik doğrulayan ve engellenen endpoint'lere hiç dokunmayan, App Store Connect'in belgelenmiş Build Uploads kaynağı. Akış şöyle:

• POST /v1/buildUploads bir yükleme oluşturur; version, build numarası ve platform parametrelerini alır.
• POST /v1/buildUploadFiles presigned object-storage yükleme URL'leri döndürür.
• IPA, presigned URL'ye 5 MB'lık parçalar halinde PUT istekleriyle gönderilir.
• PATCH /v1/buildUploadFiles/{id} dosyayı yüklenmiş olarak işaretler.

Apple ardından build'i ayrıştırır ve build TestFlight ile App Store Connect'te görünür. Yazarın belirttiği bir dikkat noktası: geçerli assetType değerleri IPA değil, ASSET, ASSET_DESCRIPTION ve ASSET_SPI'dir.

Geçiş için gerekenler

Geçiş, Users and Access ve ardından Integrations altında oluşturulan, App Manager rolü veya üzerindeki bir role sahip bir App Store Connect API anahtarı gerektiriyor. .p8 özel anahtar dosyası yalnızca bir kez indirilebilir; Key ID ve Issuer ID de bunun yanında kaydedilmelidir. Ayrıca uygulamanın sayısal App ID'si gerekiyor; bu, App Store Connect URL'sinde apps/ kısmından sonra yer alır.

Yazar tüm akışı, yalnızca yerleşik modülleri kullanarak Windows, macOS ve Linux'ta çalışan, GitHub'da yayımlanan, bağımlılığı olmayan asc-ipa-uploader adlı bir Node.js CLI'si haline getirmiş. Araç, herhangi bir aktarım yapmadan önce bir build numarasının zaten var olup olmadığını kontrol ediyor, yepyeni API anahtarlarının Apple yayılırken tetikleyebildiği geçici 401 yanıtlarını yeniden deniyor, parçalı yükleme yaparken ilerleme çıktısı veriyor ve build VALID durumuna ulaşana kadar yokluyor. Yazarın testinde 17 MB'lık bir IPA yaklaşık iki dakikada yüklenip VALID durumuna ulaşmış. Araç istenirse App Store sürümünü oluşturup build'i sonradan ekleyebiliyor.

Her zamanki uyarılar geçerli: .p8 dosyasını asla repoya commit etmeyin (CLI kimlik bilgilerini environment variable'lardan da okuyor) ve Apple yinelenen build numaralarını reddettiği için yeniden yükleme yaparken build numarasının artırılması gerekiyor.

Neden önemli

Birincisi, bu değişiklik, Mac olmayan CI hatlarının sessizce dayandığı bir kimlik doğrulama yolunu ortadan kaldırıyor. iOS uygulamalarını Xcode veya resmi Transporter uygulaması olmadan Windows ya da Linux runner'larda derleyen ekiplerin artık App Store Connect API anahtarları oluşturması ve yükleme adımlarını yeniden yazması gerekiyor. Mevcut betiklerde yamalanacak bir şey yok, çünkü reddedilme isteğin yükleme servisine ulaşmasından önce gerçekleşiyor.

İkincisi, bu, belgelenmemiş giriş akışları üzerine inşa etmenin riskinin bir hatırlatıcısı. Apple-ID-artı-app-specific-password yolu hiçbir zaman belgelenmiş bir yükleme API'si değildi ve Apple bunu bir günden bir güne ağ geçidinde kapatabildi. dev.to yazısında Apple'dan önceden bildirim yapıldığına dair bir ifade yok ve bu durum, şirketten resmi bir açıklama olmaktan çok tek bir geliştiricinin teşhisi olarak duruyor.

Üçüncüsü, geçiş ekipleri desteklenen yola taşıyor ki bu zaten tartışmasız daha iyi: kişisel Apple ID kimlik bilgileri yerine kapsamı daraltılmış ve iptal edilebilir API anahtarları, kaldığı yerden devam edebilen parçalı yüklemeler ve build geçerli olana kadar durum yoklama.