Bot Protection non agisce mai da solo: è il tuo server ad applicare l'action che riceve in risposta. La modalità decide quale sia quell'azione.
Monitor mode
Ogni nuovo account parte da qui. L'action di ogni risposta è allow, quindi nessuno viene fermato, e intended_action dice cosa farebbe il block mode. La panoramica della dashboard conta quante decisioni il block mode avrebbe bloccato e sottoposto a challenge. Inserisci la chiamata, fai il deploy e osserva per qualche giorno.
Block mode
Si può attivare quando uno dei tuoi domini è protetto: la prima decisione del tuo server su un visitatore delle tue pagine che non sia un bot lo aggiunge, e la pagina di challenge rimanda i visitatori solo a un dominio protetto. Con il block mode attivo, il tuo ultimo dominio protetto non si può rimuovere. Sulla tua macchina si può attivare appena il tag è stato eseguito su una pagina in localhost: finché uno dei tuoi domini non è protetto, la pagina di challenge rimanda allora solo i visitatori su quella macchina. Puoi anche aggiungere un dominio a mano nella pagina Set-up.
Lo attivi nella scheda Modalità della pagina Configurazione, a partire dalla richiesta successiva. L'action diventa quella che hai impostato per la classe del visitatore:
| Classe | Azione predefinita | Significa |
|---|---|---|
| human high | allow | una persona, con una prova che arriva da fuori della sessione |
| human | allow | una persona garantita dal tuo stesso feedback |
| unknown | allow | non ci sono abbastanza elementi in un senso o nell'altro; la maggior parte delle prime visite |
| bot | challenge | automazione, a giudicare da cosa fa il client |
| bot high | block | automazione, con prove solide |
Puoi cambiare l'azione di qualsiasi classe nella stessa scheda. Tornare al monitor mode è altrettanto rapido.
Cosa significa ogni azione per il tuo codice
allow: prosegui come se Bot Protection non ci fosse.challenge: chiedi qualcosa in più prima di proseguire: il tuo CAPTCHA, una verifica via email o telefono, un percorso più lento. Se non hai niente del genere, prosegui.block: rifiuta l'azione. Rispondi con lo stesso messaggio di una registrazione fallita, così il bot non impara niente.
Il block mode non impedisce mai a una pagina di caricarsi. Bot Protection giudica solo le azioni su cui il tuo server lo interroga (una registrazione, un login, un checkout), quindi un bot bloccato vede ancora il tuo sito; quello che non riesce a completare è l'azione.
La pagina di challenge
Se non hai una verifica tua, manda il visitatore sfidato alla nostra. In block mode, una risposta con action challenge porta challenge.url: reindirizza lì il browser, con &r= e l'indirizzo a cui tornare, su uno dei tuoi domini. La pagina fa risolvere al browser una piccola proof of work, al massimo qualche secondo, poi lo rimanda a quell'indirizzo con kz_token aggiunto. Il middleware conserva quel token nel cookie _kz, e per i 30 minuti successivi il challenge di quella sessione è allow, con challenge.passed a true.
Gli SDK lo fanno per te: al caricamento di una pagina (GET) senza onChallenge, protect, withKorzen e il Protect di Go mandano lì il visitatore e, quando torna, conservano kz_token e lo rimandano allo stesso indirizzo senza. Accettano il token solo da un browser che hanno mandato loro alla pagina, così un link con il token di qualcun altro non impianta nulla. L'invio di un modulo o una chiamata API in challenge viene rifiutato con 403: sfida la pagina che mostra il modulo, e il suo pass lascia passare l'invio. Un tuo hook manda il visitatore con challengeRedirect(d, returnTo) (in Go, korzen.SendToChallenge), che segna il browser allo stesso modo. L'indirizzo a cui tornare è quello che il visitatore ha chiesto, con host e schema di X-Forwarded-Host e X-Forwarded-Proto quando il tuo proxy li imposta, altrimenti di Host. Dietro un proxy che inoltra Host: localhost e nessuno dei due, come fa nginx di default, dai a publicURL (in Go, PublicURL) l'origine del tuo sito, ad esempio https://shop.example. La pagina rimanda un visitatore a localhost solo quando il tag ha visto anche la pagina del visitatore su localhost e l'IP della decisione era loopback o un indirizzo privato (un'app in Docker sulla tua macchina vede quello del bridge, come 172.17.0.1). Dietro un proxy, la pagina di un visitatore è sul tuo dominio, quindi la pagina non lo manda mai a localhost.
Un browser senza JavaScript attende invece: qualche secondo, di più per un puzzle più difficile, poi la pagina prosegue da sola e dà lo stesso pass. Nessun ritorno salta la pagina. La proof of work, o l'attesa, fa pagare a ogni sessione automatizzata la sua registrazione; da sola, non ferma un bot determinato.
Un'azione che richiede il tag
Uno script che imita un browser e invia ogni richiesta da un indirizzo nuovo non esegue mai la tua pagina, quindi è unknown, non bot, come una persona il cui blocco della pubblicità ferma il tag. Su un'azione dove questo non basta, come entrare in una coda, una registrazione o un checkout, invia "require_token": true con la decisione (l'opzione requireToken degli SDK, in Go RequireToken). Senza un token valido del tag, la risposta è challenge con token_required true, qualunque sia la classe; la classe in sé non cambia, e in monitor mode è l'intended_action. Un token fa l'azione una volta all'ora per sessione, speso dall'invio del modulo, mai dal caricamento della pagina che lo mostra: fino a tre tentativi entro due minuti sono lo stesso tentativo (una carta rifiutata, un errore di battitura), e uno successivo riceve la risposta data senza token, quindi un browser è un posto in coda. L'opzione degli SDK lo invia solo con gli invii.
Un visitatore mandato alla pagina di challenge da un'azione così non ha attesa senza JavaScript: la pagina chiede la proof of work e che il nostro tag vi sia eseguito, e questo dà un token nuovo per l'azione: uno script che risolve la proof of work senza eseguire il nostro tag non passa. Chi ha JavaScript disattivato non può superarla, quindi invia require_token solo sulle azioni che ne hanno bisogno. Un invio di modulo sotto challenge riceve il 403 degli SDK: per mandare invece il visitatore alla pagina, fallo in onChallenge con challengeRedirect(d, returnTo) verso la pagina del modulo (in Go, korzen.SendToChallenge). Quando Bot Protection è giù o lento, il tuo server continua a far passare il visitatore.
require_token rende più costoso compiere un'azione senza una visita vera: il browser del visitatore deve eseguire il nostro tag sulla tua pagina (o sulla pagina di challenge) e guadagnare un token legato a quel browser e a quella rete, speso una volta. Non è un CAPTCHA né la prova di una persona: un bot ben finanziato che imita un browser può ancora guadagnare token, lentamente e a un costo, e la nostra classificazione e il rilevamento delle farm giudicano quelle sessioni come tutte le altre.
Mettere in pausa
L'interruttore della protezione nella pagina Configurazione mette in pausa tutto senza bisogno di un deploy: ogni risposta è allow, e niente viene registrato né fatturato.