Ohne Backend verifizieren
Ein Caputchin-Token beweist nichts, bis etwas es bestätigt. Normalerweise ist dieses Etwas dein eigenes Backend, das /siteverify aufruft und entscheidet, ob es der Anfrage traut. Gehostete Verifizierung verlagert diesen Schritt auf Caputchin: dein Formular postet an eine Caputchin-Weiterleitung, Caputchin verifiziert das Token, verwirft alles, was durchfällt, und leitet nur die verifizierten Einsendungen an ein Ziel weiter, das du wählst.
Es ist dieselbe Vertrauensentscheidung wie die Backend-Prüfung, ausgeführt auf Caputchins Seite statt auf deiner. Der Punkt ist, dass es keinen /siteverify-Aufruf zu schreiben und kein Secret auf einem Server zu halten gibt, weil es keinen Server gibt.
Gehostete Verifizierung ist eine bezahlte Funktion, verfügbar ab Alpha und höher.
Für wen sie ist
Gehostete Verifizierung existiert für den Fall, in dem ein Backend zu betreiben, nur um ein Token zu prüfen, mehr ist, als das Projekt braucht.
| Du bist | Warum es passt |
|---|---|
| Eine statische Seite (Webflow, Framer, reines HTML auf einem CDN) | Es gibt keinen Server, der das Formular empfängt oder /siteverify aufruft. |
| Ein No-Code-Builder (Wix, Squarespace, Carrd) | Du kannst keinen serverseitigen Verifizierungscode hinzufügen. |
| Ein Solo-Entwickler oder kleines Team | Ein Kontakt- oder Anmeldeformular ist es nicht wert, ein Backend dafür aufzustellen und zu betreiben. |
| Schon ein Backend am Laufen, aber nicht für dieses Formular | Du kannst ein Formular auf die Weiterleitung richten und den Rest deines Stacks in Ruhe lassen. |
Betreibst du ein Backend und willst dort verifizieren, nimm stattdessen auf deinem Backend verifizieren. Die zwei sind Alternativen, keine Schichten.
Wie es funktioniert
Die Weiterleitung hält die Einsendung nur im Speicher, für den Moment, den die Zustellung dauert. Es gibt keinen Speicher zwischen dem Post und der Zustellung, und das caputchin-token-Feld wird entfernt, bevor die Payload dein Ziel erreicht.
Ziele
Du konfigurierst eines oder beide pro Site-Key. Beide zu aktivieren ist ein häufiges Muster: an einen Webhook zur Verarbeitung senden und dir selbst eine Kopie mailen.
| Ziel | Was du empfängst |
|---|---|
| Webhook | Ein JSON-POST, der deine Formularfelder plus Caputchins Verifizierungs-Metadaten trägt. |
| Eine schlichte E-Mail mit den Formularfeldern und einer Fußzeile, die vermerkt, dass Caputchin die Einsendung verifiziert hat. |
Zustellungen sind nicht signiert. Die Geheimhaltung der Weiterleitungs-URL ist es, was einen Webhook-Aufruf authentifiziert, also halt die URL aus öffentlichen Repositories und clientseitigem Code heraus. Das Setup-Tutorial zeigt die genaue Webhook-Payload.
Was privat gehalten wird
Gehostete Verifizierung folgt derselben Keine-Besucherdaten-Haltung wie der Rest von Caputchin:
- Einsendungen werden nie gespeichert. Sie leben für die Dauer der Weiterleitung im Prozessspeicher, dann sind sie weg. Bau dir am Webhook-Ende deine eigene Aufzeichnung, wenn du eine willst.
- Es werden keine Daten über den Absender erfasst. Keine IP, kein User-Agent, kein Fingerabdruck, kein Tracking.
- Telemetrie ist nur aggregiert. Caputchin zählt Zustellungserfolge und -fehlschläge, sodass du sehen kannst, ob deine Ziele gesund sind, nie den Inhalt einer Einsendung. Sieh dir Statistik an.
Wie eine kundenseitig gelieferte URL sicher gehalten wird
Eine URL, die Caputchins Server aufrufen werden, ist ein klassisches Server-Side-Request-Forgery-Risiko. Die Weiterleitung lehnt jede Webhook-URL ab, deren Host eine private, Loopback-, Link-local- oder Cloud-Metadaten-Adresse ist, sowohl wenn du sie speicherst als auch erneut direkt vor jeder Zustellung. Die blockierten Kategorien umfassen:
| Kategorie | Beispiele |
|---|---|
| Loopback und unspezifiziert | 127.0.0.1, 0.0.0.0, ::1 |
| Privat (RFC 1918) | 10.x.x.x, 172.16.x.x bis 172.31.x.x, 192.168.x.x |
| Link-local und Cloud-Metadaten | 169.254.x.x, insbesondere der Metadaten-Endpunkt 169.254.169.254 |
| Carrier-grade NAT | 100.64.x.x bis 100.127.x.x |
| Multicast und reserviert | 224.x.x.x und höher |
| Interne Hostnamen | localhost und jeder Host, der auf .local, .localhost oder .internal endet |
| Privates IPv6 | Link-local- (fe80::/10) und Unique-local- (fc00::/7) Adressen |
Kodierungen, die eine blockierte Adresse zu verschleiern versuchen, werden ebenfalls gefangen: ein Dezimal-Integer-Host wie http://2130706433/ oder ein Hex-Host wie http://0x7f000001/ (beide bedeuten 127.0.0.1) werden abgelehnt. Nur http- und https-URLs werden akzeptiert; jedes andere Schema wird abgewiesen. Die Weiterleitung weigert sich auch, Redirects zu folgen, sodass ein Webhook-Endpunkt den Aufruf nicht an ein internes Ziel abprallen lassen kann. Eine blockierte URL erscheint als generischer Fehler statt als spezifischer, sodass sie nicht genutzt werden kann, um ein Netzwerk abzutasten. Dein Webhook muss daher unter einer öffentlichen https-URL leben.
Was bewusst weggelassen ist
- Kein Einsendungs-Posteingang. Es gibt keine gespeicherte Historie von Einsendungen, die man im Dashboard durchstöbern könnte.
- Keine hauseigenen Discord-, Slack-, Telegram- oder SMS-Adapter. Nur Webhook und E-Mail. Ein Webhook kann auf deiner Seite zu jedem davon ausfächern.
- Keine Datei-Uploads. Die Weiterleitung akzeptiert Textfelder; eine Einsendung, die eine Datei trägt, wird abgelehnt.
- Keine Payload-Transformation. Was das Formular postet, ist, was dein Ziel empfängt, plus die Verifizierungs-Metadaten.
Siehe auch
- Gehostete Verifizierung einrichten: eine Anleitung, die sie zuerst an einen Test-Posteingang verdrahtet.
- Statistik der gehosteten Verifizierung: die Zustellungsgesundheit lesen.
- Auf deinem Backend verifizieren: die Alternative, wenn du doch einen Server betreibst.