Se lo spam passa nonostante il CAPTCHA, verifica innanzitutto se il server convalida l’invio da questo specifico modulo. Una checkbox visibile, il badge reCAPTCHA o un modulo attivo non bastano. La protezione deve coprire sia la generazione del token nel browser, sia la decisione del server prima della creazione dell’account, del salvataggio dell’iscrizione o dell’invio del messaggio.
Questa guida è destinata ai proprietari di negozi PrestaShop e alle persone responsabili della loro gestione tecnica. Aiuta a individuare l’origine del problema e a preparare un test verificabile. Non presuppone che ogni caso richieda la sostituzione del modulo.
1. Stabilisci da dove arriva davvero lo spam
Inizia da un solo esempio: l’ora della segnalazione, il tipo di evento e il modulo a cui lo associ. Non pubblicare l’indirizzo del cliente, il contenuto della corrispondenza privata né la richiesta completa contenente token. Nella segnalazione al programmatore bastano dati anonimizzati e istruzioni per riprodurre il problema.
Il messaggio nella casella del negozio potrebbe provenire dal contatto standard, dal modulo nella scheda prodotto, da un modulo recensioni oppure direttamente dalla posta. La protezione del modulo di contatto non filtra automaticamente i messaggi inviati a un indirizzo e-mail pubblico. Allo stesso modo, il CAPTCHA nella creazione dell’account non protegge per definizione l’iscrizione alla newsletter.
Annota l’URL esatto e il nome del modulo che gestisce il form.
Stabilisci se il problema si verifica per l’ospite, per il cliente autenticato o per entrambi i gruppi.
Riproduci la segnalazione su computer e telefono, se i moduli hanno layout diversi.
Verifica se il modulo viene inviato in modo classico, tramite AJAX o tramite un checkout esterno.
Solo con una descrizione di questo tipo confronta l’ambito di reCAPTCHA Pro per PrestaShop con il punto reale del problema. L’affermazione generica “il CAPTCHA è attivato sul sito” non consente di valutare l’efficacia di un percorso specifico.
2. Verifica il tipo di chiave, il dominio e la configurazione completa
La chiave v2, v3 e la configurazione Enterprise appartengono a modalità diverse. Il tipo di verifica impostato nel modulo deve corrispondere alla configurazione del servizio. Verifica anche il dominio utilizzato dal cliente: copia di test, dominio di produzione e host aggiuntivo non devono necessariamente avere le stesse autorizzazioni.
Nella versione analizzata di reCAPTCHA Pro 1.4.9, una chiave pubblica vuota provoca l’omissione della convalida centrale. Un modulo installato e un interruttore selezionato non sono quindi una prova di attivazione completa della protezione. Verifica che i campi richiesti per la modalità selezionata siano effettivamente compilati; non inserire la chiave privata negli screenshot né nel codice della pagina.
Imposta le limitazioni di dominio lato Google. Il codice del modulo analizzato non esegue un confronto aggiuntivo del campo hostname nella risposta. La documentazione Google sui domini spiega che la disattivazione della loro verifica richiede un controllo autonomo dell’host nel backend. Non disattivare questa limitazione come tentativo casuale di riparare il modulo.
3. Separa il funzionamento del browser dalla decisione del server
Negli strumenti per sviluppatori verifica se lo script CAPTCHA è stato caricato, se non ci sono errori JavaScript e se al momento dell’invio del modulo compare un token. Se il problema si verifica solo dopo una determinata scelta nel pannello dei cookie, segui l’ordine di caricamento degli script e l’integrazione dei consensi. Non modificare alla cieca la classificazione dei cookie solo per far sparire il messaggio di errore.
Successivamente verifica la richiesta inviata al negozio. Il token deve arrivare al percorso che esegue l’azione protetta. Nascondere il pulsante o controllare il campo solo in JavaScript non sostituisce il controllo lato server.
Google descrive il token di risposta come monouso e valido per due minuti. Un modulo lasciato aperto a lungo, il reinvio della stessa richiesta oppure due convalide indipendenti dello stesso token possono quindi concludersi con un rifiuto. Dopo un errore è necessario un nuovo tentativo corretto con un nuovo token. I dettagli e i codici di errore sono contenuti nella documentazione sulla verifica della risposta reCAPTCHA.
In v3 l’assenza della checkbox è normale. Si valutano il punteggio e il contesto dell’azione. La soglia dovrebbe derivare dall’osservazione del traffico reale; il risultato di una copia di test non deve necessariamente riflettere il comportamento della produzione. Google descrive separatamente il punteggio e il nome dell’azione. Nella diagnosi annota il motivo del rifiuto, invece di abbassare automaticamente la soglia a ogni errore.
4. Verifica l’ambito reale dei moduli
La tabella seguente descrive i percorsi trovati nel codice di reCAPTCHA Pro 1.4.9. È un’informazione sull’integrazione, non una dichiarazione del corretto funzionamento di ogni tema e di ogni versione di altri moduli.
Moduli e condizioni che richiedono verifica
Posizione
Cosa copre il codice
Cosa va confermato nel negozio
Registrazione cliente
Hook di convalida dedicati e gestione del modulo in JavaScript.
Opzione di registrazione attiva ed esecuzione degli hook nel modulo utilizzato.
Contactform standard
Override che verifica il CAPTCHA prima di inoltrare il contatto correttamente compilato all’invio.
Se l’override implementato viene eseguito e se il contatto non è gestito da un altro modulo.
Newsletter ps_emailsubscription
Hook che può bloccare l’invio e gestire il processo di conferma.
Collegamento dell’hook e riconoscimento del modulo; la conferma via e-mail è un passaggio separato.
TheCheckout
Interruttore separato e codice di integrazione.
Se la conferma finale richiama effettivamente la convalida lato server. La sola presenza del widget non lo conferma.
Login, reset password, moduli di terze parti
Non fanno parte dell’elenco predefinito dei percorsi protetti descritto sopra.
Esistenza di un’integrazione separata e verificata prima di considerare il modulo come protetto.
5. Test proprio: risposta accettata e rifiutata
Abbiamo eseguito un test controllato del codice invariato di reCAPTCHA Pro 1.4.9 e dell’override del contatto implementato. Abbiamo sostituito la risposta del servizio con dati preparati e la funzione di invio con un contatore di chiamate. Abbiamo verificato la decisione del programma; non abbiamo inviato messaggi, non abbiamo usato token dei clienti e non abbiamo misurato l’efficacia antispam di Google.
Risultati del test con risposte controllate del fornitore
Caso
Condizioni preparate
Risultato osservato
Risposta corretta del contatto
success positivo, action uguale a contact, score 0,9 con soglia 0,5.
Un solo inoltro alla funzione di invio sostitutiva, senza errore CAPTCHA.
Risposta non corretta del contatto
success negativo e codice invalid-input-response.
Nessun inoltro all’invio; messaggio di errore.
Mancanza del token
La chiave pubblica è configurata, ma il token non è stato fornito.
Il validatore rifiuta prima della chiamata al trasporto.
Punteggio v3 troppo basso
Score 0,1 con soglia 0,5.
Il validatore rifiuta.
Mancanza della chiave pubblica
Configurazione incompleta.
La convalida viene saltata; per questo la configurazione richiede un controllo separato.
Un test di questo tipo consente di verificare il punto di controllo nel codice. La validazione completa dell’implementazione richiede ancora il passaggio attraverso il modulo reale su una copia del negozio: con il suo tema, la versione di PrestaShop, il modulo del form e le impostazioni. Per un checkout esterno conferma in particolare che il rifiuto del backend blocchi l’azione finale.
6. Pensa anche all’utente normale
Dopo un rifiuto, il modulo dovrebbe spiegare il problema e consentire un nuovo tentativo. Verifica il comportamento dopo una pausa più lunga, una perdita di rete e un errore del servizio. Valuta se l’utente può conservare il contenuto inserito e se il pulsante non rimane bloccato in modo permanente. Questi sono criteri di accettazione di una specifica implementazione, non una caratteristica automatica di ogni insieme di moduli.
Se il percorso protetto funziona correttamente, ma il problema riguarda il carico massivo del server o la posta diretta, scegli una protezione adatta a quel livello. Limiti di richiesta, WAF e filtraggio della casella richiedono impostazioni separate. Il CAPTCHA non garantisce l’eliminazione di tutti i bot.
Passo successivo: verifica l’ambito di reCAPTCHA Pro per il tuo modulo. Se non riesci a indicare il punto in cui il controllo si interrompe, utilizza il supporto tecnico PrestaShop, fornendo URL, versioni e il resoconto anonimizzato del test.
Verificato il 13.09.2026. Ambito: sorgenti del modulo 1.4.9, risposte controllate del validatore e documentazione Google. L’illustrazione è materiale redazionale, non uno screenshot dell’interfaccia testata.
Google reCAPTCHA Pro è un modulo moderno per proteggere i moduli in PrestaShop da spam, bot e registrazioni false, progettato per garantire la massima efficacia e comodità d’uso. Supporta reCAPTCHA v2, v3 e reCAPTCHA Enterprise (incluse le modalità score-based e checkbox), così puoi adattare facilmente il livello di protezione alle esigenze del negozio....
Patryk Marek — proprietario di PrestaDev.pl e sviluppatore specializzato in PrestaShop. Da molti anni si occupa della creazione, dello sviluppo e della manutenzione di negozi online. Unisce il lavoro sul codice del negozio e dei moduli alla configurazione dell’ambiente server in cui queste soluzioni operano.
Progetta e sviluppa moduli PrestaShop, adatta le funzionalità esistenti e prepara integrazioni con grossisti e servizi esterni. Lavora sull’importazione e sull’aggiornamento dei dati dei prodotti, sull’automazione della gestione del catalogo, sul processo dell’ordine e sugli strumenti che supportano il lavoro quotidiano del proprietario del negozio.
La sua esperienza comprende anche aggiornamenti e migrazioni dei negozi, diagnosi degli errori, analisi delle prestazioni e configurazione dei server e dei servizi necessari al funzionamento di PrestaShop. Nella risoluzione dei problemi tiene conto delle dipendenze tra moduli, tema, PHP, database e impostazioni di hosting.
Nel blog condivide conoscenze derivanti da molti anni di pratica nello sviluppo e dal lavoro con il backend tecnico dei negozi. Le guide si concentrano su problemi concreti, sui modi per verificarli e sui limiti delle soluzioni descritte. Aiutano i proprietari dei negozi e le figure tecniche a preparare le modifiche, valutarne la portata e verificarne il risultato.
Commenti (0)