Serversideverifiering
Verifiera alltid SilentShield-nonce på din server. Kontroller enbart på klientsidan kan kringgås av bottar.
Varför serversidan?
Widgeten körs i webbläsaren och injicerar en nonce i formulär. En bot skulle kunna hoppa över widgeten och skicka in formuläret direkt. Serversideverifiering säkerställer att nonce har utfärdats och verifierats legitimt av SilentShield.
API Endpoint
- Method
POST- URL
https://api.silentshield.io/api/v1/captcha/verify-nonce- Headers
- X-Api-Key: YOUR_API_KEY Content-Type: application/json
- Body
- { "nonce": "the-nonce-from-the-form" }
Svarsformat
{
"ok": true,
"verdict": "human",
"confidence": 0.92,
"requested_nonce": "..."
}human- human — Användaren är med stor sannolikhet en människa. Behandla formuläret.
suspicious- suspicious — servern avvisade den (HTTP 403, `ok: false`). Utlåtandet anger skälet, inte beslutet: det fattades redan av ditt kontos tröskel.
bot- bot — Hög sannolikhet att detta är en bot. Avvisa formuläret.
Rekommenderad logik
Servern har redan tillämpat ditt kontos tröskel: ett avslag kommer som HTTP 403 med `ok: false`. Kontrollera därför om det släpps igenom, inte om det är `bot` — annars släpper du igenom varje avslag som avgetts som `suspicious`, och varje svar utan utlåtande (ogiltig nyckel, förbrukad kvot).
if not ok or verdict != "human":
avvisa formuläret (403)
else:
behandla formuläret normaltFelhantering
Om SilentShield API:et är onåbart (timeout, 5xx-fel), bestäm din strategi:
- Fail Open
- Öppen felhantering — Acceptera formuläret (bättre användarupplevelse, mindre säkert)
- Fail Closed
- Stängd felhantering — Avvisa formuläret (säkrare, sämre användarupplevelse)
För de flesta applikationer rekommenderar vi öppen felhantering med loggning. Kritiska formulär (inloggning, betalning) bör använda stängd felhantering.