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

Responsejson

{
  "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).

Server-Side Logicjavascript

if not ok or verdict != "human":
    avvisa formuläret (403)
else:
    behandla formuläret normalt

Formulär som skickas med AJAX

Widgeten rapporterar en inskickning när formuläret skickas med en vanlig submit. Den rapporterar också förfrågningar som görs med XMLHttpRequest, inklusive jQuery.ajax, så länge förfrågans innehåll har fältet behavior_nonce: den håller kvar förfrågan en kort stund, rapporterar skriv- och musdatan och skickar förfrågan när bedömningen har kommit, senast efter 15 sekunder. Serialisera därför hela formuläret, inklusive dolda fält. Din kontroll på serversidan ändras inte.

Omfattas inte: förfrågningar som görs med fetch() och synkrona förfrågningar. För dessa får servern ingen skriv- och musdata, och /v1/verify svarar suspicious.

Felhantering

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.