Cloudflare Üzerinde Güvenli Beta Bekleme Listelerini Nasıl Oluşturuyoruz
Bir beta bekleme listesi, ancak adresler gerçekse işletme açısından değer taşır.
Çoğu ekip tek bir email alanı ve gönder düğmesiyle başlar. Bu, bir landing page denemesi için yeterlidir. Ancak liste lansman planlarını, davet dalgalarını, yatırımcı güncellemelerini veya ürün kararlarını yönlendirmeye başladığında yeterli değildir. Herkes başkasının adresini gönderebiliyorsa ya da bir bot veritabanını bir gecede doldurabiliyorsa ekip kullanılabilir sinyal yerine gürültülü talep elde eder.
Cloudflare üzerinde production-ready bir beta bekleme listesi oluşturmak için kullandığım yöntem şu bileşenleri içerir: çift onay, server-side bot kontrolleri, kısa ömürlü doğrulama bağlantıları, hash'lenmiş token'lar, mevcut mail hosting üzerinden SMTP gönderimi, doğrulanmış ve legacy kayıtları birbirinden ayıran yönetici varsayılanları ve yapılandırılmış altyapının zaten canlı olduğunu varsaymayan bir yayınlama geçidi.
Yakın zamanda gerçekleştirilen bir beta bekleme listesi uygulaması, tam bir hesap sistemi gerektirmeden bu yöntemi gerçek bir teslimatta kanıtladı. İşin faydalı kısmı, çalışmanın şeklidir: onay, kötüye kullanım, teslimat, veri kalitesi ve deployment etrafında net sınırları olan küçük bir kayıt yüzeyi.
Güvenli Bir Bekleme Listesinin Çözdüğü İş Problemi
Bir bekleme listesinin iki görevi vardır.
Talebi toplamalı ve ekibin bu talebe göre harekete geçmesine yardımcı olmalıdır. Zayıf formların başarısız olduğu nokta ikinci kısımdır.
Listeye güvenemiyorsanız her takip süreci yavaşlar. Kaç kaydın botlardan geldiğini merak edersiniz. Davet email'leri göndermeden önce tereddüt edersiniz. Verileri dışa aktarır, manuel olarak temizler ve yine de kişinin adresi kontrol edip etmediğini bilemezsiniz. Liste, bir yayınlama aracından ziyade kabaca ölçülen bir gösteriş metriğine dönüşür.
Güvenli bir beta bekleme listesi size daha temiz girdiler sağlar:
Amaç basit bir formu gereksiz yere karmaşıklaştırmak değildir. Amaç, formun işletmenin ona yüklediği anlamı gerçekten taşımasını sağlamaktır.
Cloudflare Mimarisi
Temel stack özellikle küçüktür.
Cloudflare Workers isteği yönetir. Cloudflare Turnstile, kaydın insan tarafından yapılmış gibi görünüp görünmediğini kontrol eder. D1, bekleme listesi satırlarını ve bekleyen doğrulama kayıtlarını saklar. Mevcut SMTP/mailhosting, confirmation email'ini TLS üzerinden gönderir. Zamanlanmış bir Worker cleanup job'ı süresi dolmuş bekleyen kayıtları kaldırır.
Bu stack, erken aşamadaki birçok ekip için yeterlidir. Sorumlu bir beta listesi toplamak için tam bir user account sistemi eklemeniz gerekmez.
Akış şu şekildedir:
Bu, ürün ekiplerine net bir ayrım sağlar: bekleyen ilgi, doğrulanmış taleple aynı şey değildir.
Çift Onay Bir Ürün Kararıdır
Çift onay çoğu zaman email hijyeni olarak ele alınır. Ben bunu ürün hijyeni olarak görüyorum.
Bir beta listesi kimin önce erişim alacağına karar verecekse ekip, her adresin onu doğrulamış bir kişiye ait olduğunu bilmelidir. 24 saatlik bir onay penceresi normal bir kayıt için yeterince uzun, eski bekleyen kayıtların ortalıkta kalmasını önleyecek kadar da kısadır.
Confirmation link kendi başına state değiştirmemelidir. Link scanner'ları, email önizlemeleri ve yanlışlıkla yapılan GET istekleri vardır. Daha güvenli yöntem, bağlantının bir confirmation page oluşturmasına izin vermek ve ardından kullanıcının same-origin POST gönderen bir düğmeye basmasını zorunlu kılmaktır.
Bu ek tıklama küçüktür. Sınır ise faydalıdır.
Ayrıca desteği kolaylaştırır. Birisi kayıt olmadığını söylerse, adresin doğrulanmış listeye girmesinden önce inbox erişimi ve açık bir onay işlemi gerektiren bir akışı gösterebilirsiniz.
Düşmanca Bir Form Oluşturmadan Bot Koruması
İyi bir bekleme listesi güvenlik sınavı gibi hissettirmemelidir.
Koruma çoğunlukla formun arkasında çalışmalıdır. Bu yapıda Worker, yönetilen bir Cloudflare Turnstile widget'ını server-side olarak doğrular. Doğrulama token'ı, beklenen action'ı ve beklenen hostname'i kontrol eder. Server validation olmadan kullanılan bir browser widget'ı yalnızca dekorasyondur; Worker'ın bunu doğrulaması gerekir.
Turnstile yalnızca bir katmandır. Form ayrıca düşük maliyetli bot tespiti için bir honeypot alanı, aşırı büyük payload'ların Worker zamanını boşa harcamaması için sınırlandırılmış bir request body, keyed IP rate limiting ve adres başına keyed attempt limiting kullanır.
Adres başına limit önemlidir çünkü email doğrulama bir rahatsız etme aracına dönüşebilir. Birinin aynı inbox'a tekrar tekrar confirmation email'leri göndermesini istemezsiniz.
Public response genel kalır. Bir adresin zaten var olup olmadığını, doğrulama bekleyip beklemediğini, suppress edilip edilmediğini veya bir limite takılıp takılmadığını açığa çıkarmamalıdır. Bu, signup endpoint'inin bir email enumeration aracına dönüşmesini önler.
Token Saklama: Gönderdiğiniz Şeyi Hash'leyin
Doğrulama bağlantıları hassastır çünkü inbox erişimini kanıtlar.
Uygulama email bağlantısında rastgele bir token gönderir, ancak D1 yalnızca bu token'ın keyed hash'ini saklar. Onay sırasında Worker, gönderilen token'ı hash'ler ve saklanan hash ile karşılaştırır. Ham token veritabanında tutulmaz.
Bu tasarım, blast radius'u azaltırken sistemi basit tutar. Bekleyen doğrulama tablosu sızarsa saldırgan kullanıma hazır confirmation link'leri elde edemez.
Token tek kullanımlıktır. Başarılı bir onaydan sonra Worker bekleyen kaydı kaldırır. Süresi dolmuş bekleyen satırlar normal waitlist işlemleri sırasında fırsat buldukça ve zamanlanmış günlük bir Cloudflare Cron aracılığıyla temizlenir.
Bu cleanup yolu, manuel veritabanı işleri gerektirmeden tabloyu küçük tutar.
Mevcut Mailhosting Üzerinden Email Gönderimi
Birçok ekip zaten mail hosting kullanır. Bir beta bekleme listesi için her zaman yeni bir transactional email sağlayıcısına ihtiyaç duymazlar.
Doğruladığım uygulamada mevcut mail hosting üzerinde özel bir sender address oluşturuldu ve Worker, TLS üzerinden SMTP kullanarak gönderim yaptı. Email basitti: beta kaydını onaylayın, bağlantı 24 saat geçerlidir, isteği siz yapmadıysanız yok sayın.
Bu iş için bu kadarı yeterlidir.
Değer, gösterişli email tasarımında değildir. Değer; bilinen bir sender, dar bir amaç ve lansmandan önce smoke test yapılabilecek bir teslimat yoludur. Bir startup için bu, ürünün henüz kullanıcıları bile olmadan başka bir vendor eklemekten çoğu zaman daha iyi bir seçenektir.
Yönetici Görünümleri Ekibi Yanlış Varsayımlardan Korumalıdır
Güvenlik yalnızca public endpoint'ten ibaret değildir.
Yönetici görünümü veri sözleşmesini yansıtmalıdır. Doğrulanmış adresler varsayılan olarak gösterilmelidir. Daha eski doğrulanmamış veya legacy kayıtlar erişilebilir kalabilir, ancak açık bir filtre gerektirmelidir. CSV dışa aktarımı da aynı kuralı izlemelidir.
Bu, yaygın bir lansman hatasını önler: tüm geçmiş kayıtları dışa aktarmak ve bunları doğrulanmış talep gibi değerlendirmek.
Yakın zamanda gerçekleştirilen bir uygulamada production listesinde yeni doğrulama modelinden önce mevcut olan legacy adresler vardı. Migration planı bu adresleri legacy kayıtlar olarak korur. Yeni sistemde artık doğrulanmış bir state bulunduğu için eski satırları sessizce doğrulanmış olarak işaretlemez.
Migration ile geçmişi yeniden yazmak arasındaki fark budur.
Yapılandırılmış Olmak Canlı Olmak Değildir
Bu sınır, başka bir ekibe teslim edeceğim hizmetin bir parçasıdır.
Bir mailbox mevcut olabilir. Bir Turnstile widget'ı mevcut olabilir. Worker secret adları yapılandırılmış olabilir. Testler başarılı olabilir. Bunların hiçbiri public site'ın yeni waitlist'i henüz çalıştırdığı anlamına gelmez.
Mevcut referans uygulaması için çift onay akışı uygulanmış ve local olarak doğrulanmıştır. Bekleyen D1 migration'ı, yeni Worker sürümü ve zamanlanmış cleanup Cron'u hâlâ release onayı ve deployment gerektirir. Bu gerçekleşene kadar public site eski waitlist formunu çalıştırmaya devam eder.
Bu ayrım işletmeyi korur. Bir D1 migration'ı production veri yapısını değiştirir. Bir Worker deploy'u kayıt davranışını değiştirir. Bir Cron arka planda mutation ekler. Her adım açık bir release window, doğrulama ve rollback planlaması gerektirir.
Güvenli bir bekleme listesi, üzerinde secure kelimesi bulunduğu için gelişigüzel yayınlanmamalıdır.
Doğrulama Nasıl Görünür?
Production-ready bir bekleme listesi teslimatı için lansmandan önce kanıt görmek isterim.
Referans uygulaması 150 testi geçti. Astro check 0 hata bildirdi. Production build başarılı oldu. Çalışma yalnızca web kapsamındaydı; bu nedenle mevcut native app değişikliklerine dokunulmadı.
Bundan sonra da release checklist önemini korur:
“Code compiles” ile “signup funnel traffic almaya hazır” arasındaki fark budur.
Bu Yapı Startuplara Nerede Yardımcı Olur?
Bu model, bir ekip beta'ya yaklaşmış ancak henüz tam hesaplara hazır değilken kullanışlıdır.
Bir mobile app, SaaS aracı, private alpha, gated AI özelliği veya hardware reservation listesi başlatıyor olabilirsiniz. Talep toplamanız gerekir, ancak davet göndermeye başlamadan önce temiz verilere ve onaya da ihtiyacınız vardır.
Güvenli bir Cloudflare waitlist, büyük bir backend eklemeden bunu sağlar:
Hızlıca yayınlanabilecek kadar küçük, güvenilebilecek kadar katıdır.
Ürününüz İçin Buna İhtiyacınız Var mı?
Bir ürün ekibi için bu tür bir signup flow'u tasarlamaya, güvenli hâle getirmeye veya uygulamaya yardımcı olabilirim.
Faydalı iş, bir forma CAPTCHA eklemek değildir. Faydalı iş; bir signup'ın ne anlama geldiğine, onayın nasıl kanıtlandığına, token'ların nerede tutulduğuna, email'in nasıl gönderildiğine, yöneticilerin varsayılan olarak ne gördüğüne ve public traffic gelmeden önce release'in nasıl doğrulandığına karar vermektir.
Beta listeniz launch planınızın bir parçası hâline gelmek üzereyse, karar vermek için kullanmadan önce listeyi güvenilir hâle getirmeye değer.