Verificare pe server

Verificați întotdeauna nonce-ul SilentShield pe serverul dumneavoastră. Verificările doar pe client pot fi ocolite de boți.

De ce pe server?

Widgetul rulează în browser și injectează un nonce în formulare. Un bot ar putea sări peste widget și trimite formularul direct. Verificarea pe server asigură că nonce-ul a fost emis și verificat în mod legitim de SilentShield.

Endpoint API

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" }

Format răspuns

Responsejson

{
  "ok": true,
  "verdict": "human",
  "confidence": 0.92,
  "requested_nonce": "..."
}

human: human — Utilizatorul este foarte probabil om. Procesați formularul.
suspicious: suspicious — serverul a respins-o (HTTP 403, `ok: false`). Verdictul numește motivul, nu decizia: aceasta a fost luată deja de pragul contului dumneavoastră.
bot: bot — Încredere ridicată că acesta este un bot. Respinge formularul.

Logică recomandată

Serverul a aplicat deja pragul contului dumneavoastră: o respingere ajunge ca HTTP 403 cu `ok: false`. Verificați așadar trecerea, nu `bot` — altfel lăsați să treacă orice respingere pronunțată ca `suspicious` și orice răspuns fără verdict (cheie invalidă, cotă epuizată).

Server-Side Logicjavascript

if not ok or verdict != "human":
    respinge formularul (403)
else:
    procesează formularul normal

Formulare trimise prin AJAX

Widgetul raportează o trimitere când formularul este trimis cu un submit obișnuit. Raportează și solicitările făcute cu XMLHttpRequest, inclusiv jQuery.ajax, atât timp cât corpul solicitării conține câmpul behavior_nonce: reține solicitarea pentru scurt timp, raportează datele despre tastare și mouse și trimite solicitarea imediat ce sosește verdictul, cel târziu după 15 secunde. Serializați deci întregul formular, inclusiv câmpurile ascunse. Verificarea dvs. de pe server nu se schimbă.

Neacoperite: solicitările făcute cu fetch() și solicitările sincrone. Pentru acestea serverul nu primește date despre tastare și mouse, iar /v1/verify răspunde suspicious.

Gestionarea erorilor

Dacă API-ul SilentShield nu poate fi contactat (timeout, eroare 5xx), decideți strategia:

Fail Open: Fail open — Acceptă formularul (UX mai bun, mai puțin sigur)
Fail Closed: Fail closed — Respinge formularul (mai sigur, UX mai slab)

Pentru majoritatea aplicațiilor, recomandăm fail open cu logare. Formularele critice (autentificare, plată) ar trebui să folosească fail closed.