Skift til Turnstile – servervalidering er stadig obligatorisk

Skifter du fra reCAPTCHA til Cloudflare Turnstile, skal du ændre både formularen og den backend, der modtager den. Cloudflares krav til tokenvalidering er klart: Widgetten alene beskytter ikke formularen. Backend skal sende tokenet til Siteverify og først behandle indsendelsen, når svaret er godkendt.

Behold den gamle kontrol som afgørende for indsendelsen, mens du afprøver Turnstile på de samme formularveje. Før Turnstile overtager, skal både formular og backend kunne håndtere et gyldigt token, et afvist token og et manglende token. Automatiske tests bør bruge særskilte testnøgler, så resultatet ikke afhænger af, hvilken udfordring en browser får.

Kortlæg formularer og endpoints før skiftet

Find alle steder, hvor reCAPTCHA bruges: kontaktformularer, login, usynlige udfordringer, mobilvisninger og alternative endpoints til de samme handlinger. Registrér, hvilket felt hvert endpoint læser, og hvor den nuværende verifikation foretages. En formular kan se korrekt ud efter et scriptskift, selv om en ældre indsendelsesvej stadig springer den nye serverkontrol over.

Opret Turnstile-konfigurationen til de værtsnavne, hvor formularerne skal bruges. Sitekey er offentlig og hører til widgetten; den tilhørende hemmelige nøgle skal opbevares på serveren. Hold konfigurationerne for udvikling, automatiske tests og produktion adskilt, så testtokens ikke sendes til en produktionsnøgle, og en testnøgle ikke bliver afgørende for rigtige indsendelser.

Udskift frontend og følg tokenet til backend

Cloudflares migrationsvejledning beskriver en kompatibilitetstilstand til og med reCAPTCHA v2. Med compat=recaptcha kan Turnstile bruge formularfeltet g-recaptcha-response og registrere sit API som grecaptcha. Den eksisterende sitekey skal erstattes med en Turnstile-sitekey, men kompatibiliteten ændrer ikke kravet om at udskifte serverens verifikation.

Vælger du Turnstiles almindelige integration, er standardfeltet cf-turnstile-response. Kontrollér i en faktisk indsendelse, at backend læser netop det felt, som formularen sender; et omdøbt eller manglende felt skal give afvisning. Under parallel drift bør de to integrationer have adskilte felter og kald, så deres tokens ikke forveksles. Bruger den gamle løsning en scorebaseret beslutning, skal den regel gennemgås særskilt frem for at blive videreført som om de to svar havde samme format.

Lad Siteverify afgøre hver indsendelse

Backend skal sende tokenet som response sammen med den hemmelige nøgle som secret i en POST-anmodning til Turnstiles Siteverify-endpoint. Endpointet accepterer formularindhold eller JSON og returnerer JSON. En eksisterende reCAPTCHA-integration, der verificerer med GET, kan derfor ikke nøjes med at få udskiftet endpointets adresse. Det afgørende svarfelt er success; et token, der blot findes i anmodningen, er ikke et godkendt token.

Sammenhold også svarets hostname med det forventede værtsnavn for den pågældende indsendelsesvej. Har du angivet en action på widgetten, bør backend kontrollere, at den stemmer med handlingen, som endpointet udfører. De kontroller er særligt relevante, når flere formularer eller miljøer deler kode: Et positivt success-svar skal stadig høre til den rigtige formular og det rigtige værtsnavn.

Et Turnstile-token udløber efter fem minutter og kan kun valideres én gang. Et udløbet eller genbrugt token kræver derfor et nyt token, før brugeren kan prøve igen. Hvis Siteverify ikke kan nås, svaret ikke kan læses, eller hostname ikke passer, må formularens handling ikke fortsætte. Vis en kort besked om, at indsendelsen skal prøves igen, og registrér fejlen på serveren uden at eksponere den hemmelige nøgle. Ved et nødvendigt forsøg på at gentage selve valideringsanmodningen understøtter Siteverify en idempotency_key; det er noget andet end at genbruge tokenet i en ny formularindsendelse.

Brug testnøgler til både succes og fejl

Cloudflares testnøgler giver forudsigelige svar til automatiske forløb: Der findes kombinationer, som godkender, afviser eller returnerer fejlen timeout-or-duplicate. Brug både en test-sitekey i formularen og en tilsvarende test-secret på serveren. En produktionsnøgle afviser de dummy-tokens, som test-sitekeys udsteder.

Test hele forløbet fra formular til den handling, endpointet udfører. En godkendt validering skal lade handlingen fortsætte; et afvist svar skal stoppe den. Test derudover en anmodning uden token. Forkert hostname, forkert action og en afbrudt forbindelse til Siteverify kan afprøves med styrede svar i applikationens egne tests, så det er backend-beslutningen, der kontrolleres. Testen bør ikke kræve, at en automatiseret browser får en bestemt interaktiv udfordring.

Testnøgler virker også på localhost. For sitekeys, der bruges i produktion, frarådes det derimod at tillade localhost og 127.0.0.1. Afslut derfor med en særskilt kontrol på det rigtige produktionsværtsnavn og med produktionsnøglerne. Et vellykket lokalt testforløb viser ikke i sig selv, at værtsnavn og nøgler er sat rigtigt i drift.

Skift håndhævelse, før reCAPTCHA fjernes

En overgang kan begynde med, at reCAPTCHA fortsat bestemmer, om indsendelsen behandles, mens backend validerer Turnstile-tokenet og registrerer resultatet. Brug særskilte tokens til de to tjenester. Turnstile-tokenet må ikke sendes til Siteverify igen, når håndhævelsen senere flyttes; nye indsendelser skal levere nye tokens. Når formularvejene er gennemgået, kan Turnstile blive den kontrol, der afgør behandlingen.

Stopkriteriet er, at alle beskyttede endpoints afviser manglende, ugyldige, genbrugte og forkert tilknyttede tokens, mens gyldige indsendelser går igennem med produktionsnøgler. Automatiske succes- og fejltests skal passere med testnøgler, og ingen alternativ formularvej må omgå servervalideringen. Først derefter kan det gamle script, serverkaldet og den gamle hemmelige nøgle fjernes.

Læs også:

• Automation Anywhere køber Boost.ai – kundeservice kobles til bagkontoret
• DMARC uden mailnedbrud: Gå fra p=none til p=reject i trin
• ChatGPT eller Perplexity til research? Kilderne kræver stadig kontrol