Verifica lato server
Verifichi sempre il Nonce di SilentShield sul Suo server. I controlli solo lato client possono essere aggirati dai bot.
Perché lato server?
Il Widget viene eseguito nel browser e inietta un Nonce nei moduli. Un bot potrebbe saltare il Widget e inviare il modulo direttamente. La verifica lato server garantisce che il Nonce sia stato legittimamente emesso e verificato da 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" }
Formato della risposta
{
"ok": true,
"verdict": "human",
"confidence": 0.92,
"requested_nonce": "..."
}human- human — L'utente è molto probabilmente umano. Elaborare il modulo.
suspicious- suspicious — il server ha rifiutato (HTTP 403, `ok: false`). Il verdetto indica il motivo, non la decisione: quella è già stata presa dalla soglia del suo account.
bot- bot — Alta probabilità che si tratti di un bot. Rifiutare il modulo.
Logica consigliata
Il server ha già applicato la soglia del suo account: un rifiuto arriva come HTTP 403 con `ok: false`. Verifichi quindi il passaggio, non `bot` — altrimenti lascia passare ogni rifiuto emesso come `suspicious` e ogni risposta priva di verdetto (chiave non valida, quota esaurita).
if not ok or verdict != "human":
rifiutare il modulo (403)
else:
elaborare il modulo normalmenteModuli inviati con AJAX
Il widget segnala un invio quando il modulo viene inviato con un normale submit. Segnala anche le richieste effettuate con XMLHttpRequest, compreso jQuery.ajax, purché il corpo della richiesta contenga il campo behavior_nonce: trattiene la richiesta per un attimo, segnala i dati di digitazione e del mouse e invia la richiesta non appena arriva il verdetto, al più tardi dopo 15 secondi. Serializzi quindi l’intero modulo, campi nascosti inclusi. La Sua verifica lato server non cambia.
Non coperte: le richieste effettuate con fetch() e le richieste sincrone. Per queste il server non riceve dati di digitazione e del mouse e /v1/verify risponde suspicious.
Gestione degli errori
Se l'API di SilentShield non è raggiungibile (timeout, errore 5xx), scelga la Sua strategia:
- Fail Open
- Fail open — Accettare il modulo (migliore esperienza utente, meno sicuro)
- Fail Closed
- Fail closed — Rifiutare il modulo (più sicuro, peggiore esperienza utente)
Per la maggior parte delle applicazioni, consigliamo il fail open con registrazione dei log. I moduli critici (accesso, pagamento) dovrebbero utilizzare il fail closed.