Turnstile Spin eksik sunucu doğrulamasını buluyor; kodu ajan değiştiriyor

Cloudflare, 25 Eylül 2026 tarihli Turnstile Spin yazısında, trafik aldığı hâlde Siteverify çağrısı görülmeyen mevcut bileşenler için panoda “Fix with Spin” seçeneği gösterildiğini anlattı. Bu seçenek, eksik sunucu doğrulamasını geliştiricinin kullandığı kodlama ajanıyla tamamlamaya yönelik. Ajan ilgili ön yüz ve arka uç kodunu buluyor, bir değişiklik planı hazırlıyor ve kodu değiştirmeden önce onay bekliyor.

25 Eylül 2026 tarihli The Clarity değerlendirmesi, ajanın planı dışında kalan bir formun veya API yolunun korunmayacağını vurguluyor. Dolayısıyla Spin uyarısını kullanmanın amacı yalnızca panodaki işareti kaldırmak değil; form isteğini alan sunucunun Turnstile belirtecini doğrulayıp başarısız sonucu gerçekten reddetmesini sağlamak. Sayfada görünen bir bileşen, bu sunucu kararı olmadan formu korumuyor.

“Fix with Spin” hangi eksikliği gösteriyor?

Turnstile bileşeni ziyaretçinin tarayıcısında bir belirteç üretiyor. Formu işleyen sunucunun belirteci Siteverify API’ye göndermesi ve aldığı yanıta göre korunan işlemi sürdürmesi veya durdurması gerekiyor. Cloudflare, bileşen bazında Siteverify çağrılarını izliyor; trafik alan bir bileşen için sunucu doğrulaması görülmediğinde “Fix with Spin” uyarısı sunabiliyor. Mevcut bileşeni kurtarma akışında ajan aynı gizli anahtarı kullanarak eksik adımı arka uca ekliyor; bileşen bu sırada trafik almaya devam ediyor.

Uyarının kapsamı sınırlı: Siteverify çağrısının görülmemesi, eksik doğrulama için güçlü bir işaret. Çağrının görülmesi ise uygulamanın yanıttaki başarısızlığı dikkate aldığını kanıtlamaz. Aynı bileşen farklı formlarda kullanılıyorsa bir işleyici doğrulama yaparken diğeri isteği denetimsiz kabul ediyor olabilir. Panoda uyarı bulunmaması bu nedenle bütün form yollarının güvenli olduğu sonucunu tek başına vermez.

Ajanın önerdiği kod neden geliştirici onayı bekliyor?

Spin’de geliştirici korunacak alanı seçiyor; ajan bileşenin yerini ve form isteğini karşılayan sunucu işleyicisini arayıp ekleme planını sunuyor. Mevcut bileşeni düzeltirken beklenen değişiklik, görsel bileşeni yeniden kurmak yerine belirteci ilgili arka uç işleyicisinde Siteverify kararına bağlamak. Cloudflare uygulama kodunu uzaktan değiştirmiyor: Onaylanan düzenleme geliştiricinin kendi kod tabanında, kullandığı ajan tarafından yapılıyor.

Planın onaylanması, güvenlik kararının hangi isteklere uygulanacağını da belirliyor. Geliştirici önerilen değişiklikte formun gerçek gönderim yolunu, aynı işlemi yapan başka uç noktaları ve doğrulamanın kayıt ya da giriş gibi korunan işlemden önce çalıştığını incelemeli. Ajan bir sayfadaki formu bulup aynı arka uç işlemine ulaşan başka bir yolu atladıysa, yapılan düzenleme yalnızca bulduğu yolu kapsar.

Gizli anahtarın konumu da değişikliğin parçası. Herkese açık site anahtarı bileşende kullanılabilir; Siteverify isteği için gereken gizli anahtar sunucu ortamında tutulmalı. Önerilen kodun bu anahtarı tarayıcıya, kod deposuna veya kullanıcıya dönen yanıta taşımaması gerekir. Spin’in kodu düzenlemesi ayrıca uygulamayı geliştirici adına yayına aldığı anlamına gelmez; değişikliğin incelenmesi ve dağıtılması uygulamanın kendi geliştirme sürecinde kalır.

Siteverify yanıtı sunucuda nasıl karara dönüşür?

Cloudflare’ın sunucu doğrulama kılavuzuna göre belirteç beş dakika geçerli ve tek kullanımlık; yeniden kullanılan belirteç “timeout-or-duplicate” hatasıyla reddediliyor. Sunucu, formdan gelen belirteci kendi gizli anahtarıyla Siteverify API’ye gönderiyor. API, JSON yanıtındaki success alanıyla doğrulamanın sonucunu bildiriyor. Tarayıcıdaki başarı görünümü veya gönder düğmesinin etkinleşmesi, bu sunucu yanıtının yerine geçmiyor.

İşleyici korunan işlemi yalnızca doğrulama başarılıysa sürdürmeli. Belirteç eksikse, Siteverify başarısız yanıt verirse veya API’ye erişilemiyorsa isteği normal gönderim gibi işlemek korumayı etkisiz bırakır. Uygulama belirli bir action değeri kullanıyorsa yanıttaki değeri beklenen işlemle karşılaştırmalı; hostname alanı da yayındaki alan adıyla eşleşmeli. Böylece başka bir işlem veya alan adı için alınmış geçerli bir belirteç yanlış yerde kabul edilmez.

Hata sonrası aynı belirteci yeniden göndermek çözüm değildir, çünkü başarılı doğrulamada kullanılmış bir belirteç tekrar geçmez. Sayfa gönderim denemesinden sonra açık kalıyorsa yeni deneme için bileşenin yeni bir belirteç üretmesi gerekir. Sunucunun döndürdüğü hata kullanıcıya yeniden deneme olanağı verebilir; ancak doğrulama tamamlanmadan korunan işlem gerçekleşmemelidir.

Mevcut formdaki düzeltme nasıl gözden geçirilir?

Spin’in önerdiği değişiklik, pano uyarısından sunucunun son kararına kadar aynı form akışında izlenebilir:

1. Turnstile panosunda uyarı veren bileşeni ve onun kullanıldığı formu belirleyin. Form gönderimini alan arka uç işleyicisini, varsa aynı işlemi yapan diğer yollarla birlikte eşleştirin.
2. Ajanın planında belirtecin gelen istekten alındığını, Siteverify çağrısının sunucuda yapıldığını ve gizli anahtarın yalnızca sunucu yapılandırmasından okunduğunu inceleyin. Planın kapsadığı yolları gördükten sonra kod değişikliğini onaylayın.
3. Önerilen kodda başarısız doğrulamanın korunan işlemi durdurduğunu kontrol edin. Kullanılan action ve hostname değerlerinin beklenen form işlemine ve dağıtım alan adına uyduğunu doğrulayın.
4. Dağıtımdan sonra geçerli belirteçle gönderimi; eksik, geçersiz ve yeniden kullanılan belirteçlerle reddi deneyin. Siteverify erişim hatasında işleyicinin korunan işlemi sürdürmediğini de doğrulayın.

Şu anda doğrulanan kapsam, Siteverify trafiği görülmeyen bileşenlerin işaretlenmesi ve eksik kod adımının geliştirici onayıyla eklenmesi. Cloudflare’ın pano sinyali, sunucu işleyicisinin her başarısız yanıtı doğru ele aldığını göstermiyor. Düzeltmenin sonucu, yayındaki korunan uç noktanın geçerli isteği kabul edip doğrulanamayan isteği reddetmesiyle belirlenir.

Ayrıca okuyun:

• Cloudflare 100 TB RAM kazandı: Donanım değil, veri düzeni değişti
• GitHub etiketleri artık silinmeden arşivleniyor, otomasyon ise eksik
• npm kurtarma kodu 72 saat yayın kapatıyor; tüm hesaplar kapsamda