Bot Protection handelt nie selbst: Ihr Server wendet die action an, die es antwortet. Der Modus bestimmt, welche Aktion das ist.
Monitor-Modus
Jedes neue Konto beginnt hier. Die action jeder Antwort ist allow, also wird niemand gestoppt, und intended_action sagt, was der Block-Modus tun würde. Die Übersicht im Dashboard zählt, wie viele Entscheidungen der Block-Modus blockiert und herausgefordert hätte. Bauen Sie den Aufruf ein, deployen Sie und beobachten Sie ein paar Tage.
Block-Modus
Er lässt sich einschalten, sobald eine Ihrer Domains geschützt ist: Die erste Entscheidung Ihres Servers zu einem Besucher Ihrer Seiten, der kein Bot ist, fügt sie hinzu, und die Challenge-Seite schickt Besucher nur auf eine geschützte Domain zurück. Solange der Block-Modus an ist, lässt sich Ihre letzte geschützte Domain nicht entfernen. Auf Ihrem eigenen Rechner lässt er sich einschalten, sobald das Tag auf einer Seite auf localhost lief: Bis eine Ihrer Domains geschützt ist, schickt die Challenge-Seite dann nur Besucher auf diesem Rechner zurück. Sie können eine Domain auch von Hand auf der Set-up-Seite hinzufügen.
Schalten Sie ihn in der Karte Modus der Seite Einrichtung ein; er gilt ab der nächsten Anfrage. Die action ist dann die, die Sie für die Klasse des Besuchers festgelegt haben:
| Klasse | Standardaktion | Bedeutet |
|---|---|---|
| human high | allow | ein Mensch, mit einem Nachweis außerhalb der Session |
| human | allow | ein Mensch, für den Ihr eigenes Feedback bürgt |
| unknown | allow | nicht genug Belege in die eine oder andere Richtung; die meisten ersten Besuche |
| bot | challenge | Automatisierung, erkannt an dem, was der Client tut |
| bot high | block | Automatisierung, mit starken Belegen |
Sie können die Aktion jeder Klasse in derselben Karte ändern. Der Wechsel zurück in den Monitor-Modus geht genauso schnell.
Was jede Aktion für Ihren Code bedeutet
allow: weitermachen, als gäbe es Bot Protection nicht.challenge: vor dem Weitermachen mehr verlangen: Ihr CAPTCHA, eine Prüfung per E-Mail oder Telefon, einen langsameren Weg. Haben Sie nichts davon, einfach weitermachen.block: die Aktion ablehnen. Antworten Sie mit derselben Meldung wie bei einer fehlgeschlagenen Registrierung, damit ein Bot nichts lernt.
Der Block-Modus hindert nie eine Seite am Laden. Bot Protection beurteilt nur die Aktionen, nach denen Ihr Server fragt (eine Registrierung, eine Anmeldung, einen Checkout), ein blockierter Bot sieht Ihre Website also weiterhin; was er nicht abschließen kann, ist die Aktion.
Die Challenge-Seite
Ohne eigene Prüfung schicken Sie einen herausgeforderten Besucher zu unserer. Im Block-Modus enthält eine Antwort mit action challenge das Feld challenge.url: Leiten Sie den Browser dorthin weiter, mit &r= und der Adresse, zu der er zurückkehren soll, auf einer Ihrer Domains. Die Seite lässt den Browser einen kleinen Proof of Work lösen, höchstens einige Sekunden, und schickt ihn dann mit angehängtem kz_token an diese Adresse zurück. Die Middleware speichert dieses Token als Cookie _kz, und in den nächsten 30 Minuten ist das challenge dieser Session allow, mit challenge.passed auf true.
Die SDKs erledigen das für Sie: Bei einem Seitenaufruf (GET) ohne onChallenge schicken protect, withKorzen und Protect in Go den Besucher dorthin, speichern bei seiner Rückkehr kz_token und leiten ihn ohne das Token an dieselbe Adresse weiter. Sie nehmen das Token nur von einem Browser an, den sie selbst zur Seite geschickt haben: Ein Link mit dem Token eines anderen pflanzt nichts ein. Ein abgeschicktes Formular oder ein API-Aufruf mit Challenge wird mit 403 abgelehnt: Fordern Sie die Seite heraus, die das Formular zeigt, und der Pass lässt das Formular durch. Ein eigener Hook schickt den Besucher mit challengeRedirect(d, returnTo) (in Go korzen.SendToChallenge), das den Browser genauso markiert. Die Adresse für die Rückkehr ist die, die der Besucher aufgerufen hat: mit Host und Schema aus X-Forwarded-Host und X-Forwarded-Proto, wenn Ihr Proxy sie setzt, sonst aus Host. Hinter einem Proxy, der Host: localhost und keinen der beiden weiterreicht, wie nginx es standardmäßig tut, geben Sie publicURL (in Go PublicURL) den Origin Ihrer Website an, etwa https://shop.example. Die Seite schickt einen Besucher nur dann zu localhost zurück, wenn der Tag auch die Seite des Besuchers auf localhost sah und die IP der Entscheidung Loopback oder eine private Adresse war (eine App in Docker auf Ihrem Rechner sieht die der Bridge, etwa 172.17.0.1). Hinter einem Proxy liegt die Seite eines Besuchers auf Ihrer Domain, daher schickt die Seite ihn nie zu localhost.
Ein Browser ohne JavaScript wartet stattdessen: ein paar Sekunden, länger bei einem schwereren Puzzle, dann geht die Seite von selbst weiter und gibt denselben Pass. Es gibt keinen Rückweg, der die Seite überspringt. Der Proof of Work oder das Warten lässt jede automatisierte Session für ihre Registrierung bezahlen; allein hält er einen entschlossenen Bot nicht auf.
Eine Aktion, die den Tag braucht
Ein Skript, das einen Browser nachahmt und jede Anfrage von einer neuen Adresse sendet, führt Ihre Seite nie aus, also ist es unknown, nicht bot, wie eine Person, deren Werbeblocker den Tag stoppt. Bei einer Aktion, bei der das nicht genügt, etwa dem Eintritt in eine Warteschlange, einer Registrierung oder einem Checkout, senden Sie "require_token": true mit der Entscheidung (die Option requireToken der SDKs, in Go RequireToken). Ohne gültiges Token vom Tag ist die Antwort challenge mit token_required true, gleich welche Klasse; die Klasse selbst ändert sich nicht, und im Monitor Mode ist es die intended_action. Ein Token führt die Aktion einmal pro Stunde und Session aus, verbraucht durch das Absenden des Formulars, nie durch den Seitenaufruf, der es zeigt: bis zu drei Versuche innerhalb von zwei Minuten sind derselbe Versuch (eine abgelehnte Karte, ein Tippfehler), ein späterer wird beantwortet, als gäbe es kein Token, also ist ein Browser ein Platz in der Warteschlange. Die Option der SDKs sendet es nur beim Absenden.
Ein Besucher, der von einer solchen Aktion zur Challenge-Seite geschickt wird, hat ohne JavaScript kein Warten: Die Seite verlangt den Proof of Work und dass unser Tag auf ihr läuft, und beides gibt ein neues Token für die Aktion: Ein Skript, das den Proof of Work löst, ohne unseren Tag auszuführen, kommt nicht durch. Wer JavaScript ausgeschaltet hat, kommt nicht durch; senden Sie require_token also nur bei den Aktionen, die es brauchen. Ein Formular-Post unter challenge bekommt das 403 der SDKs: Um den Besucher stattdessen zur Seite zu schicken, tun Sie es in onChallenge mit challengeRedirect(d, returnTo) zur Seite des Formulars (in Go korzen.SendToChallenge). Ist Bot Protection ausgefallen oder langsam, lässt Ihr Server den Besucher weiterhin durch.
require_token verteuert eine Aktion ohne echten Besuch: Der Browser des Besuchers muss unseren Tag auf Ihrer Seite (oder auf der Challenge-Seite) ausführen und ein Token verdienen, das an diesen Browser und dieses Netz gebunden ist und einmal ausgegeben wird. Es ist kein CAPTCHA und kein Beweis für einen Menschen: Ein gut finanzierter Bot, der einen Browser nachahmt, kann weiterhin Tokens verdienen, langsam und mit Kosten, und unsere Klassifizierung und Farm-Erkennung beurteilen diese Sitzungen wie jede andere.
Pausieren
Der Schutzschalter auf der Einrichtungsseite pausiert alles ohne Deploy: Jede Antwort ist allow, nichts wird aufgezeichnet oder berechnet.