--- type: how-to title: Die Aufgabe anpassen summary: Wähle ein Spiel oder eine Checkbox mit einem Tipp, nagle Sprache und Design fest, und benenne das Cookie und den Callback-Pfad um, die das Gate auf deinem Origin nutzt. --- Die Verifizierungsseite, die das Gate zeigt, wird pro Site-Key konfiguriert, auf dessen Seite **Proxy-Gate** im Dashboard, und über die [Management-API](/docs/automation/management-api), MCP und Terraform wie jede andere Einstellung. Jede Option unten steht standardmäßig auf dem Verhalten, das du schon hast, also läuft ein Site-Key, den du nie anfasst, genau weiter wie bisher. ## Wähle ein Spiel oder eine Checkbox **Aufgabentyp** entscheidet, was der Besucher tatsächlich tut: | Typ | Was der Besucher tut | Wann es passt | |---|---|---| | **Ein Spiel spielen** | Spielt ein kurzes Verifizierungsspiel in der Seite | Stärkeres Signal gegen Bots. Der Standard. Kostet den Besucher ein paar Sekunden. | | **Mit einer Checkbox bestätigen** | Tippt einmal, während eine Proof-of-Work-Prüfung läuft | Schneller, leichter, kein Spiel zu installieren. Schwächeres Signal. | Zwei Regeln schränken die Wahl ein: - **Ein Site-Key mit Spielpflicht zeigt immer ein Spiel.** Ist die Einstellung **Spiel zum Verifizieren verlangen** am Site-Key selbst an, oder verlangt dein Team ein Spiel auf jedem Key, ist die Checkbox-Option nicht verfügbar, und das Dashboard sagt, welche Einstellung sie festnagelt. Sie über die API zu setzen gibt `409 gate-forces-game-mode` zurück. - **Ein Spiel zu wählen braucht ein installiertes Spiel.** Der Site-Key braucht mindestens ein installiertes Spiel mit einem abspielbaren Artefakt, ein eigenes oder eins vom Team geerbt. Ohne eines gibt es `409 no-games`, wenn du den Typ Spiel *wählst*. Das Gate einzuschalten allein nicht: ein Site-Key ohne Spielpflicht fällt auf die Checkbox zurück, also läuft das Gate weiter, während du die Spiele sortierst. Wird das letzte installierte Spiel später entfernt, hört ein Site-Key mit Spielpflicht auf, die Verifizierung auszuliefern, statt still auf etwas anderes zurückzufallen, weil eine Checkbox auf einem Key mit Spielpflicht nicht verifizieren kann. Ein Key *ohne* Spielpflicht fällt auf die Checkbox zurück, damit deine Site erreichbar bleibt. Diesen letzten Fall solltest du erkennen können, denn er nimmt eine Site mit Gate vom Netz: das Gate antwortet jedem Besucher mit einer Seite „Verifizierung nicht verfügbar“, bis wieder ein Spiel verfügbar ist. Er kann auch eintreten, ohne dass jemand eine Einstellung ändert, denn ein Spiel zählt erst, wenn seine gepinnte Version unsere Determinismus-Prüfung bestanden hat. Die Seite Proxy-Gate warnt, sobald ein Site-Key in diesem Zustand ist, und verlinkt sowohl die Spieleliste als auch die Einstellung, die ein Spiel verlangt, damit du entweder eines installierst oder die Pflicht aufhebst und die Checkbox übernehmen lässt. ## Nagle eine Sprache oder ein Design fest **Sprache** und **Design** stehen beide standardmäßig auf *dem Besucher folgen*, und das ist fast immer, was du willst: - **Sprache** folgt der eigenen Browsersprache des Besuchers, in denselben elf Sprachen, die das Widget unterstützt. - **Design** folgt der Hell- oder Dunkel-Vorliebe des Systems des Besuchers, und wechselt mit ihr. Nagle stattdessen eines fest, wenn die abgesicherte Site einsprachig ist, oder wenn sie auf ein Design festgelegt ist und die Verifizierung dazu passen soll, statt dem Gerät des Besuchers zu folgen. So oder so trägt die Verifizierungsseite **das Branding dieses Site-Keys**: denselben Markennamen, dasselbe Logo, dieselben Farben und Links wie dein Widget, aufgelöst aus demselben Site-Key. Das konfigurierst du einmal, in den Aussehen-Einstellungen deines Widgets, und das Gate übernimmt es. Eigene Marken-Presets brauchen den Apex-Plan, so wie beim Widget auch; die Sprach- und Design-Optionen selbst laufen in jedem Plan, in dem es das Gate gibt. Der Wortlaut der Verifizierungsseite selbst ist nicht anpassbar. ## Cookie und Callback-Pfad umbenennen Änder das nur, wenn die Standardwerte mit deiner App kollidieren. **Cookie-Name** (Standard `cpt_gate`) ist das First-Party-Cookie, das dein Proxy aus dem Pass setzt. Benenn es um, wenn deine App diesen Namen schon nutzt, oder wenn du mehrere abgesicherte Apps auf einer Domain betreibst und sie unabhängig freigeben willst. **Von einem eigenen Namen auf einen anderen umzubenennen legt deine abgesicherte Site lahm, bis du das Reverse-Proxy-Snippet von der Seite Proxy-Gate deines Site-Keys erneut kopierst und deinen Proxy neu lädst.** Das Gate sucht den neuen Namen, während dein Proxy noch den alten schreibt, also wird ein Besucher zur Verifizierung geschickt, besteht sie, und wird sofort wieder dorthin geschickt, in einer Schleife, die an einem Rate-Limit endet. Weg vom Standard `cpt_gate` zu wechseln ist dagegen unbedenklich, erst umstellen und danach verdrahten, weil das Gate den Standard weiterhin erkennt. **Das Feld, das an deinen Callback gePOSTet wird, heißt immer `cpt_gate`**, egal wie du das Cookie nennst. Das Body-Parsing deines Callbacks ändert sich also nie; nur der Name, den er in `Set-Cookie` schreibt. Die Antwort des Gates enthält ein Feld `cookie_name`, das deinem Callback sagt, welchen Namen er nutzen soll. **Callback-Pfad** (Standard `/__cpt/callback`) ist die Route auf deinem eigenen Origin, die den Pass entgegennimmt und das Cookie setzt. Verschieb ihn, wenn der Router deiner App diesen Pfad schon belegt. Er muss ein einfacher Pfad auf deinem Origin sein: kein Schema, kein Host, kein Query-String, kein Fragment. ## Das Gate auf einige Pfade beschränken **Nur diese Pfade abdecken** und **Diese Pfade nie abdecken** nehmen ein Muster pro Zeile und formen die erzeugte Reverse-Proxy-Konfiguration. Lass beide leer, und jeder Pfad ist abgesichert. Sie sind beratend: sie ändern das Snippet, das du kopierst, und durchgesetzt werden sie von deinem Proxy. Lass die Autorisierer-Subrequest und deinen Callback-Pfad immer ungeschützt, was die erzeugte Konfiguration schon für dich tut. Ein typisches Login-Portal: ``` Nur diese Pfade abdecken: / /api/firstfactor Diese Pfade nie abdecken: /api/verify /healthz ``` ## Siehe auch - [Das Proxy-Seiten-Gate einrichten](/docs/proxy-page-gate/set-up): die nginx-Durchgehung. - [Reverse-Proxy-Rezepte](/docs/proxy-page-gate/reverse-proxy-recipes): der Callback-Vertrag und die anderen Proxys. - [Überblick](/docs/proxy-page-gate/overview): das Konzept und das Freigabe-Cookie.