Så bygger vi säkra betaväntelistor på Cloudflare
En betaväntelista är bara en affärstillgång om adresserna är riktiga.
De flesta team börjar med ett e-postfält och en skicka-knapp. Det fungerar bra för ett experiment på en landningssida. Det räcker inte när listan börjar styra lanseringsplaner, inbjudningsvågor, investeraruppdateringar eller produktbeslut. Om vem som helst kan skicka in någon annans adress, eller om en bot kan fylla databasen över en natt, får teamet brusig efterfrågan i stället för användbara signaler.
Det här är metoden jag använder för att bygga en produktionsklar betaväntelista på Cloudflare: double opt-in, botkontroller på serversidan, kortlivade verifieringslänkar, hashade tokens, SMTP-leverans via befintlig e-posthosting, administratörsstandarder som skiljer verifierade och äldre poster åt, samt en releasegrind som inte låtsas att konfigurerad infrastruktur redan är live.
En nylig implementation av en betaväntelista bevisade metoden i en verklig leverans utan att kräva ett fullständigt kontosystem. Det användbara är arbetets struktur: en liten registreringsyta med tydliga gränser kring samtycke, missbruk, leverans, datakvalitet och driftsättning.
Affärsproblemet som en säker väntelista löser
En väntelista har två uppgifter.
Den ska samla in efterfrågan och hjälpa teamet att agera utifrån den efterfrågan. Det är den andra delen som svaga formulär misslyckas med.
Om du inte kan lita på listan blir varje uppföljning långsammare. Du undrar hur många poster som kommer från botar. Du tvekar innan du skickar inbjudningsmejl. Du exporterar data, rensar den manuellt och vet fortfarande inte om personen kontrollerar adressen. Listan blir ett grovt fåfängomått i stället för ett lanseringsverktyg.
En säker betaväntelista ger dig renare indata:
Målet är inte att göra ett enkelt formulär komplicerat. Målet är att få formuläret att betyda det som verksamheten tror att det betyder.
Cloudflare-arkitekturen
Den centrala stacken är medvetet liten.
Cloudflare Workers hanterar begäran. Cloudflare Turnstile kontrollerar om registreringen verkar mänsklig. D1 lagrar väntelistposter och väntande verifieringsposter. Befintlig SMTP/e-posthosting skickar bekräftelsemejlet över TLS. Ett schemalagt Worker-rensningsjobb tar bort utgångna väntande poster.
Den stacken räcker för många team i ett tidigt skede. Du behöver inte lägga till ett fullständigt användarkontosystem bara för att samla in en ansvarsfull betaväntelista.
Flödet ser ut så här:
Det ger produktteam en tydlig uppdelning: väntande intresse är inte samma sak som verifierad efterfrågan.
Double opt-in är ett produktbeslut
Double opt-in framställs ofta som e-posthygien. Jag ser det som produkthygien.
Om en betaväntelista ska avgöra vem som får tillgång först bör teamet veta att varje adress tillhör någon som har bekräftat den. Ett bekräftelsefönster på 24 timmar räcker för en normal registrering och är tillräckligt kort för att förhindra att gamla väntande poster blir kvar.
Bekräftelselänken bör inte ändra tillstånd på egen hand. Länkskannrar, e-postförhandsvisningar och oavsiktliga GET-förfrågningar förekommer. Det säkrare mönstret är att låta länken visa en bekräftelsesida och därefter kräva att användaren trycker på en knapp som skickar en POST-förfrågan från samma origin.
Det extra klicket är litet. Gränsen är användbar.
Det gör också supporten enklare. Om någon säger att de aldrig registrerade sig kan du hänvisa till ett flöde som krävde åtkomst till inkorgen och en uttrycklig bekräftelseåtgärd innan adressen lades till i den verifierade listan.
Bot-skydd utan ett fientligt formulär
En bra väntelista ska inte kännas som ett säkerhetsprov.
Skyddet bör till största delen ligga bakom formuläret. I den här lösningen validerar Workern en hanterad Cloudflare Turnstile-widget på serversidan. Valideringen kontrollerar tokenen, förväntad åtgärd och förväntat hostname. En webbläsarwidget utan servervalidering är bara dekoration; Workern måste verifiera den.
Turnstile är bara ett lager. Formuläret använder också ett honeypot-fält för enkel botdetektering, en begränsad request body så att överdimensionerade nyttolaster inte slösar Worker-tid, nycklad IP-hastighetsbegränsning och nycklad begränsning av försök per adress.
Begränsningen per adress är viktig eftersom e-postverifiering kan bli ett sätt att störa andra. Du vill inte att någon upprepade gånger ska kunna utlösa bekräftelsemejl till samma inkorg.
Det offentliga svaret förblir generiskt. Det bör inte avslöja om en adress redan finns, väntar på verifiering, är blockerad eller har nått en gräns. Det förhindrar att registreringsendpointen används för att kartlägga e-postadresser.
Tokenlagring: hasha det du skickar
Verifieringslänkar är känsliga eftersom de bevisar åtkomst till inkorgen.
Implementationen skickar en slumpmässig token i e-postlänken, men D1 lagrar endast en nycklad hash av tokenen. Vid bekräftelse hashar Workern den inskickade tokenen och jämför den med den lagrade hashen. Den råa tokenen finns inte i databasen.
Den designen håller systemet enkelt samtidigt som den minskar skadeomfattningen. Om tabellen med väntande verifieringar läcker får angriparen inga färdiga bekräftelselänkar.
Tokenen kan bara användas en gång. Efter en lyckad bekräftelse tar Workern bort den väntande posten. Utgångna väntande poster rensas opportunistiskt under normalt väntelistearbete och genom en schemalagd daglig Cloudflare Cron.
Den rensningsvägen håller tabellen liten utan manuellt databasarbete.
E-postleverans via befintlig e-posthosting
Många team har redan e-posthosting. De behöver inte alltid en ny leverantör av transaktionell e-post för en betaväntelista.
I den implementation jag verifierade skapades en särskild avsändaradress på befintlig e-posthosting, och Workern skickar via SMTP över TLS. Mejlet är enkelt: bekräfta betaregistreringen, länken är giltig i 24 timmar, ignorera det om du inte begärde det.
Det räcker för den här uppgiften.
Värdet ligger inte i avancerad e-postdesign. Värdet ligger i en känd avsändare, ett tydligt syfte och en leveransväg som kan testas innan lansering. För ett startupföretag är det ofta bättre än att lägga till ännu en leverantör innan produkten ens har användare.
Administratörsvyer bör skydda teamet från felaktiga antaganden
Säkerhet gäller inte bara den offentliga endpointen.
Administratörsvyn måste återspegla datakontraktet. Verifierade adresser bör visas som standard. Äldre overifierade eller äldre poster kan fortfarande vara tillgängliga, men de bör kräva ett uttryckligt filter. CSV-exporten bör följa samma regel.
Det förhindrar ett vanligt lanseringsmisstag: att exportera alla historiska poster och behandla dem som bekräftad efterfrågan.
I en nylig implementation innehöll produktionslistan redan äldre adresser innan den nya verifieringsmodellen infördes. Migreringsplanen behåller dessa adresser som äldre poster. Den markerar inte gamla poster som verifierade i tysthet bara för att det nya systemet nu har ett verifierat tillstånd.
Det är skillnaden mellan migrering och att skriva om historien.
Konfigurerat är inte samma sak som live
Den här gränsen är en del av tjänsten jag skulle leverera till ett annat team.
En brevlåda kan finnas. En Turnstile-widget kan finnas. Worker-hemligheternas namn kan vara konfigurerade. Tester kan gå igenom. Inget av detta betyder att den offentliga webbplatsen redan kör den nya väntelistan.
För den aktuella referensimplementationen är double-opt-in-flödet implementerat och verifierat lokalt. Den väntande D1-migreringen, den nya Worker-versionen och den schemalagda rensnings-Cron behöver fortfarande releasegodkännande och driftsättning. Den offentliga webbplatsen kör fortfarande det gamla väntelisteformuläret tills det sker.
Den skillnaden skyddar verksamheten. En D1-migrering ändrar produktionsdatastrukturen. En Worker-driftsättning ändrar registreringsbeteendet. En Cron lägger till bakgrundsändringar. Varje steg behöver ett uttryckligt releasefönster, verifiering och en plan för återställning.
En säker väntelista bör inte lanseras vårdslöst bara för att den har ordet säker kopplat till sig.
Så ser verifieringen ut
För en produktionsklar väntelisteleverans vill jag ha bevis före lansering.
Referensimplementationen klarade 150 tester. Astro check rapporterade 0 fel. Produktionsbygget lyckades. Arbetet gällde endast webben, så befintliga ändringar i native-appar lämnades orörda.
Releasechecklistan är fortfarande viktig efter det:
Det är skillnaden mellan att ”koden kompilerar” och att ”registreringsflödet är redo för trafik”.
Var detta hjälper startups
Det här mönstret är användbart när ett team närmar sig beta men inte är redo för fullständiga konton.
Du kanske lanserar en mobilapp, ett SaaS-verktyg, en privat alpha, en gated AI-funktion eller en reservationslista för hårdvara. Du behöver samla in efterfrågan, men också rena data och samtycke innan du börjar skicka inbjudningar.
En säker Cloudflare-väntelista ger dig det utan att lägga till en stor backend:
Den är tillräckligt liten för att driftsättas snabbt och tillräckligt strikt för att kunna litas på.
Behöver du detta för din produkt?
Jag kan hjälpa till att utforma, säkra eller implementera den här typen av registreringsflöde för ett produktteam.
Det användbara arbetet är inte att lägga en CAPTCHA på ett formulär. Det är att besluta vad en registrering betyder, hur samtycke bevisas, var tokens lagras, hur e-post levereras, vad administratörer ser som standard och hur releasen verifieras innan offentlig trafik når den.
Om din betaväntelista snart blir en del av din lanseringsplan är det värt att göra listan tillförlitlig innan du använder den för att fatta beslut.