Come funziona reCAPTCHA v2 e come risolverlo (in arrivo)
reCAPTCHA v2 è il captcha classico di Google. Mostra una casella con la scritta "Non sono un robot" e, quando non è sicuro del visitatore, aggiunge una sfida con immagini. Un solver per questo tipo deve produrre un token di risposta valido che il sito possa verificare con Google. Il supporto di Scarnox per reCAPTCHA v2 è in arrivo. Questa guida spiega come funziona il widget, gli approcci generali usati oggi e cosa aspettarsi da un solver basato su token.
Scarnox non risolve ancora reCAPTCHA v2 in produzione. L'unico tipo di attività attivo oggi è PopularCaptcha, proxyless. Se il tuo progetto ha bisogno di reCAPTCHA v2 subito, gli approcci qui sotto sono le opzioni realistiche.
Come funziona il widget
La pagina incorpora un elemento contenitore con un attributo data-sitekey. Quella sitekey identifica il sito presso Google. Quando il widget si carica, esegue controlli nel browser, osservando il comportamento del visitatore, i cookie e la cronologia, e invia una valutazione del rischio a Google.
Se la valutazione indica un rischio basso, la casella si spunta da sola e il widget scrive un token in un campo nascosto chiamato g-recaptcha-response. Se la valutazione indica un rischio più alto, il visitatore vede una sfida con immagini, come selezionare i riquadri che contengono un certo oggetto. Anche superare la sfida scrive il token.
Il backend del sito invia poi il token all'endpoint di verifica di Google, insieme alla chiave segreta del sito. Google risponde con successo o fallimento. Poiché la verifica avviene sul server, un modulo che accetta un token senza verificarlo con Google non è protetto da reCAPTCHA affatto.
Perché viene segnalato
La casella è una decisione di rischio, non un enigma. I fattori che la fanno scattare più spesso sono:
- una raffica di richieste da un solo indirizzo IP;
- una nuova sessione del browser senza cookie né cronologia;
- un ambiente del browser che sembra automatizzato, come una configurazione headless predefinita;
- uno schema di input che non sembra una persona che muove il mouse o digita.
Capire questi fattori conta più del widget stesso. Se il tuo traffico non fa scattare la casella, non vedrai mai la sfida con immagini.
Approcci generali che funzionano oggi
Questi approcci sono usati ampiamente, e sono onesti. Riducono la frequenza con cui compare una sfida nel lavoro legittimo.
- Mantieni sessioni reali. Riutilizza i cookie e un profilo di browser coerente durante una sessione, invece di ripartire da zero a ogni pagina.
- Scandisci le richieste. Un ritmo costante e lento assomiglia molto più a una persona di una raffica.
- Usa un browser reale per il widget. Un browser completo con impostazioni normali è meno soggetto a segnalazioni di una configurazione headless spogliata. La guida al rilevamento del browser headless elenca i segnali comuni.
- Chiedi un'eccezione o una chiave di test. Se sei il titolare del sito, usa le chiavi di test pubblicate da Google in staging. Se non lo sei, chiedi al titolare una lista di indirizzi autorizzati.
- Inserisci una persona nel processo. Per attività a basso volume, una persona può completare la casella e passare il token. È lento ma affidabile.
Questi approcci non garantiscono che una sfida non compaia mai. Ne riducono la frequenza, ed è questo che mantiene stabile un lavoro legittimo.
Cosa farà un solver basato su token
Un solver basato su token per reCAPTCHA v2 fa ciò che PopularCaptcha fa oggi. Prende la sitekey e l'URL della pagina, produce un token g-recaptcha-response valido e lo restituisce al tuo codice. Il tuo codice inserisce poi il token nel modulo e lo invia prima che scada.
Scarnox documenterà il tipo di attività e gli eventuali campi aggiuntivi nel riferimento API quando il supporto a reCAPTCHA v2 sarà disponibile. Fino ad allora, non costruire su un'interfaccia presunta. La forma della richiesta sarà simile all'esempio di PopularCaptcha, ma verifica nella documentazione i valori esatti.
Checklist per un lavoro con reCAPTCHA v2
Quando pianifichi un lavoro che tocca un modulo reCAPTCHA v2, controlla questi punti:
- Il sito è tuo? Se sì, usa le chiavi di test in staging e mantieni minimi i test in produzione.
- Il lavoro è legittimo? La raccolta di dati pubblici e i tuoi flussi di lavoro lo sono; l'abuso di account e lo spam no.
- La frequenza è abbastanza bassa da far restare silenziosa la casella?
- Hai un piano per la sfida con immagini, sia una persona sia un solver quando ne sarà disponibile uno?
- Controlli il risultato della verifica lato server, e non solo la presenza di un token?
Errori comuni
Il problema più frequente in un'integrazione reCAPTCHA v2 è un token che il sito rifiuta anche se sembra corretto. Tre cause spiegano la maggior parte dei casi. La prima è una mancata corrispondenza tra sitekey e URL della pagina: il token è legato alla pagina su cui è stato mostrato il widget, quindi una sitekey presa da una pagina e inviata a un'altra fallirà. La seconda è un token scaduto. I token sono di breve durata, quindi uno script che risolve per primo e poi esegue una lunga sequenza di altri passaggi invierà un valore scaduto. La terza è l'assenza di un controllo lato server dalla tua parte. Se i tuoi test confermano solo che un token esiste, non noterai che il passaggio di verifica sta fallendo.
Un secondo gruppo di errori nasce dal flusso di lavoro attorno al widget. Effettuare il login su una sessione e poi inviare il modulo da un'altra è un errore comune, perché la verifica può dipendere dalla sessione che ha caricato il widget. Anche ritentare molte volte di seguito un modulo rifiutato fa apparire sospetta la sessione, e può trasformare una singola sfida in una serie. Quando qualcosa fallisce, fermati, controlla lo stato della pagina e riprova una volta con valori nuovi.
Scraping responsabile
Se il modulo fa parte di un lavoro di scraping, controlla robots.txt e i termini del sito prima di iniziare. Mantieni bassa la frequenza e non raccogliere dati personali che non ti servono. La guida sulla legalità del web scraping copre le considerazioni principali.