Die Aufgabe anpassen

Die Verifizierungsseite, die das Gate zeigt, wird pro Site-Key konfiguriert, auf dessen Seite Proxy-Gate im Dashboard, und über die 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:

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.

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.

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: die nginx-Durchgehung.
• Reverse-Proxy-Rezepte: der Callback-Vertrag und die anderen Proxys.
• Überblick: das Konzept und das Freigabe-Cookie.