Kurumsal İletişim Formunda Cloudflare Turnstile Doğrulaması Nasıl Kurulur?

Kurumsal iletişim formunda Cloudflare Turnstile kullanmak, forma bir doğrulama bileşeni eklemekten ibaret değildir. Güvenilir kurulumda tarayıcı bir token üretir, form bu tokenı sunucuya taşır ve sunucu mesajı işlemeye başlamadan önce Cloudflare Siteverify yanıtını doğrular. Bu son adım yoksa arayüzde görünen bileşen tek başına form uç noktasını korumaz. Amaç, istenmeyen otomatik gönderimleri azaltırken gerçek müşterinin teklif veya iletişim talebini kaybetmemektir.

Turnstile kurulumunda önce hangi akış çizilmeli?

Formun bugün nasıl çalıştığını çıkarın: Kullanıcı hangi sayfadan geliyor, hangi alanları dolduruyor, gönderim hangi sunucu uç noktasına gidiyor, başarılı talep nerede saklanıyor ve ekibe nasıl bildiriliyor? Spam filtresi ancak bu yolun üzerine doğru yere yerleştirilirse anlamlıdır. Talep verisi e-postaya, CRM'e veya başka bir sisteme gidiyorsa doğrulama tamamlanmadan o sistemlere yazılmamalıdır. Aksi halde ziyaretçiye hata gösterilirken ekip tarafında sahte kayıt oluşabilir.

İletişim ile teklif formlarını aynı sanmayın. Uzun teklif formunda kullanıcının dosya eklemesi veya ayrıntılı açıklama yazması zaman alabilir; kısa iletişim formunda ise talep birkaç alanla tamamlanır. Tokenın üretim anı, hata mesajı ve yeniden deneme davranışı buna göre planlanmalıdır. Alanların ne için istendiği açıkça yazılmalı, zorunlu alanlar gereksiz yere çoğaltılmamalıdır. Doğrulama katmanı kötü bir form deneyimini tek başına düzeltemez.

Cloudflare'ın güncel başlangıç kılavuzu tarayıcıdaki widget ile sunucudaki Siteverify kontrolünü birlikte tanımlar. Bu, form geliştirirken sınırı belirler: görünür bileşen kullanıcı deneyiminin, sunucu kontrolü ise kabul kararının parçasıdır.

Sitekey ve secret key nasıl ayrılır?

Turnstile widget'ı oluşturulurken bir sitekey ve bir secret key alınır. Sitekey, sayfada bileşeni çağırmak için kullanılır; gizli anahtar yalnızca sunucuda tutulur. Gizli anahtarın HTML'ye, tarayıcı JavaScript'ine, istemci günlüklerine veya kamuya açık depoya girmemesi gerekir. Geliştirme ve canlı ortam için ayrı yapılandırma kullanmak, yanlış anahtarın yanlış alan adında çalışması gibi sorunları ayırmayı kolaylaştırır.

Widget'ın izin verilen alan adlarını da kontrol edin. Site yalnızca belirli alan adlarından form kabul ediyorsa yapılandırma buna uymalıdır. Fakat alan adı kısıtını sunucu doğrulamasının yerine koymayın. Form gönderildiğinde sunucu hem zorunlu alanları hem de doğrulama sonucunu değerlendirir. Başarısız yanıtta mesajı normal bir talep gibi işlememek temel kabul kuralıdır.

Başka bir CAPTCHA ürününden geçiliyorsa eski kodun tümüyle kaldırıldığını, iki farklı doğrulamanın aynı formu bloke etmediğini ve test anahtarlarının canlı ortama taşınmadığını ayrıca inceleyin. Geçişi yalnızca anahtar değişimi olarak görmek, istemci ve sunucu beklentilerini farklı bırakabilir.

Sunucu doğrulamasını hangi sırayla yapmalı?

İstemciden gelen token, diğer form alanlarıyla birlikte kendi sunucunuza ulaşır. Sunucu gizli anahtarı ve tokenı Cloudflare'ın Siteverify uç noktasına iletir; dönen başarı durumuna göre talebi kabul eder veya reddeder. Cloudflare'ın sunucu tarafı doğrulama dokümanı bu çağrının zorunlu olduğunu açıkça belirtir. Formu doğrudan tarayıcıdan e-posta hizmetine gönderen bir yapıda, doğrulama kararını verecek güvenilir bir sunucu katmanı önce tasarlanmalıdır.

Doğrulama başarılı olsa bile iş alanları ayrıca kontrol edilir. E-posta biçimi, açıklama uzunluğu, dosya türü, zorunlu onaylar ve kötü niyetli içerik sunucuda ele alınır. Turnstile, veri doğrulaması, erişim sınırı ve kötüye kullanım gözleminin yerine geçen tek bir güvenlik kalkanı değildir. Aynı isteğin ağ hatası nedeniyle tekrar gelmesi halinde iki talep oluşturulmaması için kayıt akışını da gözden geçirin.

Token başarısız olduğunda kullanıcıya teknik hata kodunu aynen göstermek yerine anlaşılır bir açıklama ve yeniden deneme yolu verin. Kullanıcının yazdığı uzun açıklama silinmemeli; güvenli biçimde korunup doğrulama yenilendiğinde tekrar gönderilebilmelidir. Sunucu geçici olarak doğrulama hizmetine ulaşamazsa sessizce her talebi kabul etmek yerine işletmenin risk iştahına göre bir hata ve alternatif iletişim yolu sunulmalıdır.

Süresi dolmuş veya yeniden kullanılan token ne olur?

Cloudflare'ın güncel dokümanına göre tokenlar sınırlı süre geçerlidir ve tek kullanımlıktır. Uzun süre açık bırakılan formda veya aynı talebin tekrar gönderilmesinde doğrulama başarısız olabilir. Bu nedenle sadece 'gönder' düğmesini yeniden etkinleştirmek yeterli değildir; yeni bir token üretilmesi ve kullanıcıya neden tekrar denediğinin açıklanması gerekir.

Özellikle uzun teklif formlarında doğrulamayı sayfa açıldığı anda başlatıp kullanıcının metni tamamlamasını beklemek sorun yaratabilir. Widget'ın çalışma biçimini ve form akışını birlikte test edin. Çok sekmeli kullanım, tarayıcı geri tuşu, bağlantı kesilip geri gelmesi ve mobil klavyede formun uzun süre açık kalması gerçekçi denemelerdir. Teknik olarak başarılı görünen bir kurulum, bu senaryolarda değerli bir talebi kaybettirebilir.

İstek kayıtlarında yalnızca gerekli teknik sinyalleri saklayın. Gizli anahtarı, tam form içeriğini veya kişisel bilgileri hata günlüğüne gereksiz yere yazmayın. Başarısız doğrulamaların artışı, belirli tarayıcılarda yoğunlaşması ya da her gerçek kullanıcının aynı adımda takılması farklı sorunlara işaret eder. Ölçüm yapılırken güvenlik ve mahremiyet birlikte değerlendirilmelidir.

Yayına almadan önce nasıl test edilir?

Önce test anahtarlarıyla normal gönderimi, boş tokenı, süresi dolmuş tokenı ve ağ hatasını deneyin. Ardından canlı anahtarlarla kendi alan adınızda yeniden test yapın. Widget ekranda görünse de form uç noktasına widget'ı atlayarak istek gönderilebileceğini varsayın; bu isteğin sunucuda reddedildiğini doğrulayın. Tamamlanan talebin e-posta veya CRM'e bir kez ulaştığını da kontrol edin.

Mobil görünümde widget'ın alanları örtmediğine, klavye açıkken gönder düğmesine erişilebildiğine ve hata mesajının ekran okuyucu ile anlaşılabildiğine bakın. Kullanıcı doğrulamayı geçse bile form alanı hatası aldığında token yenileme davranışını deneyin. Formun ölçüm olayları varsa 'butona tıkladı', 'doğrulama geçti' ve 'talep gerçekten kaydedildi' adımlarını aynı dönüşüm sayısına indirgemeyin.

Cloudflare'ın form kötüye kullanımına ilişkin 2026 rehberi Turnstile'ı tekrarlı istek sınırları ve diğer kontrollerle birlikte ele alır. Bu yüzden kurulumu tamamlandı diye spam sorununun bütünüyle bittiğini varsaymayın; şüpheli desenleri ve gerçek kullanıcı hatalarını izleyin.

Webinle ile hangi kapsamı netleştirmeli?

Webinle'nin kurumsal web yazılım hizmeti kapsamında formun arayüzünü, sunucu kabul kuralını ve operasyonel teslimini tek akış olarak değerlendirmek gerekir. Talep CRM'e aktarılacaksa CRM entegrasyonlu teklif formu planı sonraki aşama için uygundur; bu yazının konusu ise özellikle bot doğrulaması ve hatasız form kabulüdür. Mevcut formunuzda spam veya kaybolan gerçek talepler varsa, proje kapsamını paylaşırken kullanılan form sistemi, sunucu altyapısı ve yaşanan hata örneklerini belirtin. Böylece çözüm, yalnızca ekrana bir widget koymaya değil, çalışan bir talep akışına dayanır.