Eine ganze Site am Reverse-Proxy per Gate schützen

Der normale Weg, Caputchin zu nutzen, ist, das Widget auf einer Seite einzubetten und das Token von deinem Backend zu verifizieren. Das braucht einen Platz für das Widget und ein Backend, das das Token prüft. Das Proxy-Gate braucht keines von beiden. Es setzt eine Ganzseiten-Verifizierung vor eine ganze Site oder Route an deinem Reverse-Proxy: ein Besucher löst ein Spiel, verdient einen kurzlebigen Pass, und streift durch die Site, bis der Pass abläuft. Die geschützte App wird nie angerührt.

Weil der App selbst nichts hinzugefügt wird, ist das der Weg, Hosts zu schützen, in die du kein Skript einbetten kannst, ein kompiliertes Single-Page-Login-Portal, eine Appliance, oder ein internes Werkzeug, das hinter einem Auth-Proxy sitzt.

Für wen es ist

Greif zum Gate, wenn das Inline-Widget nicht passt:

• Die App hat keinen Platz für das Widget. Ein versiegeltes Login-Portal (wie Authelia), eine Anbieter-Appliance, oder jede UI, die du nicht bearbeiten kannst.
• Du willst eine ganze Fläche absichern, nicht ein Formular. "Beweise, dass du ein Mensch bist, bevor du diese Site erreichst" statt einer Prüfung bei einem einzelnen Absenden.
• Du hast kein Backend, um ein Token zu verifizieren. Der Proxy übernimmt die Durchsetzung; es gibt keinen /siteverify-Aufruf zu schreiben.

Für eine normale Seite oder ein Formular, das du kontrollierst, bette stattdessen das Widget ein, es ist leichter und leitet den Besucher nicht um. Hast du ein Formular, aber kein Backend, passt die gehostete Verifizierung besser.

Wie es funktioniert

Ein Lösen kauft viele Anfragen. Der Besucher spielt das Spiel einmal; danach gibt ein First-Party-Cookie seine Anfragen frei, bis es abläuft.

Der Proxy macht bei jeder Anfrage einen kleinen Autorisierer-Aufruf an Caputchin. Trägt die Anfrage keinen gültigen Pass, antwortet Caputchin 401 und der Proxy leitet den Besucher zur gehosteten Challenge um. Ist der Pass vorhanden und gültig, antwortet Caputchin 204 und der Proxy lässt die Anfrage zu deiner App durch.

Das Freigabe-Cookie

Der Pass lebt in einem First-Party-Cookie namens cpt_gate, das ein kleiner Callback, den du hostest, auf deiner eigenen Domain setzt. Es ist ein signiertes, kurzlebiges Token, nicht an ein Gerät gebunden, also kommt seine Sicherheit ganz aus den Cookie-Attributen (HttpOnly, Secure, SameSite=Lax) und einer kurzen TTL, die du wählst. Weil es ein Cookie bei deinen Besuchern setzt, weise es in deiner Cookie-Richtlinie aus. Der Setup-Leitfaden geht den Callback und die nötigen Attribute durch.

Was bewusst weggelassen ist

• Kein selbstgehostetes Gate. Caputchin hostet die Challenge und verifiziert den Pass; du betreibst keinen Verifizierer. Dein Proxy leitet nur ein Cookie weiter und folgt Umleitungen.
• Eine Prüfung pro Anfrage, keine lokale Token-Validierung. Der Proxy fragt Caputchin bei jeder Anfrage. Der Fail-Modus, den du wählst (offen oder geschlossen), entscheidet, was passiert, wenn Caputchin kurz nicht erreichbar ist.
• Freigabe pro Site-Key, cookie-gebunden. Ein Pass gibt einen Origin frei, nicht ein ganzes Konto oder mehrere Domains, weil es ein gewöhnliches First-Party-Cookie ist.
• Keine Session und kein Login. Das Gate beweist, dass ein Mensch die Site erreicht hat; deine App erledigt weiterhin die Authentifizierung und ihre eigenen Rate-Limits. Die beiden stapeln sich.

Siehe auch

• Das Proxy-Gate einrichten: aktiviere es und verdrahte deinen Proxy von Ende zu Ende.
• Reverse-Proxy-Rezepte: nginx, Traefik, Caddy, und das durchgearbeitete Authelia-Beispiel.
• Proxy-Gate-Statistik: lies das Verhältnis von Durchgang zu Challenge.
• Gehostete Verifizierung: die Option ohne Backend, wenn du doch ein Formular hast, das du auf uns richten kannst.