Pokud spam prochází navzdory CAPTCHA, nejprve ověřte, zda server ověřuje odeslání z tohoto konkrétního formuláře. Viditelný checkbox, odznak reCAPTCHA nebo aktivní modul nestačí. Ochrana musí zahrnovat jak vygenerování tokenu v prohlížeči, tak rozhodnutí serveru před vytvořením účtu, uložením odběru nebo odesláním zprávy.
Tento návod je určen majitelům obchodů PrestaShop a osobám odpovědným za jejich technickou správu. Pomáhá určit zdroj problému a připravit ověřitelný test. Nepředpokládá, že každý případ vyžaduje výměnu modulu.
1. Zjistěte, kudy spam skutečně přichází
Začněte jedním příkladem: časem odeslání, typem události a formulářem, se kterým ji spojujete. Nezveřejňujte adresu zákazníka, obsah soukromé korespondence ani celý požadavek obsahující tokeny. V hlášení pro vývojáře stačí anonymizované údaje a návod k reprodukci problému.
Zpráva ve schránce obchodu mohla pocházet ze standardního kontaktu, formuláře na kartě produktu, modulu recenzí nebo přímo z pošty. Ochrana kontaktního formuláře automaticky nefiltruje zprávy odesílané na veřejnou e-mailovou adresu. Stejně tak CAPTCHA při zakládání účtu ze své podstaty nezabezpečuje přihlášení k newsletteru.
Zapište přesnou URL a název modulu obsluhujícího formulář.
Určete, zda se problém vyskytuje u hosta, přihlášeného zákazníka nebo u obou skupin.
Reprodukujte hlášení na počítači i telefonu, pokud se formuláře liší rozložením.
Zkontrolujte, zda je formulář odesílán klasicky, přes AJAX nebo přes externí checkout.
Teprve s takovým popisem porovnávejte rozsah reCAPTCHA Pro pro PrestaShop se skutečným místem problému. Obecné tvrzení „CAPTCHA je na stránce zapnutá“ neumožňuje posoudit účinnost konkrétní cesty.
2. Zkontrolujte typ klíče, doménu a kompletní konfiguraci
Klíč v2, v3 a konfigurace Enterprise patří do různých režimů. Typ ověření nastavený v modulu musí odpovídat konfiguraci služby. Zkontrolujte také doménu, kterou zákazník používá: testovací kopie, produkční doména a další host nemusí mít stejná oprávnění.
V prověřené verzi reCAPTCHA Pro 1.4.9 prázdný veřejný klíč způsobuje přeskočení centrální validace. Nainstalovaný modul a zapnutý přepínač tedy nejsou důkazem kompletního spuštění ochrany. Ověřte, zda jsou požadovaná pole zvoleného režimu skutečně vyplněna; soukromý klíč neuvádějte na screenshotech ani v kódu stránky.
Omezení domén nastavujte na straně Google. Prověřený kód modulu neprovádí dodatečné porovnání pole hostname v odpovědi. Dokumentace Google k doménám vysvětluje, že vypnutí jejich ověřování vyžaduje vlastní kontrolu hosta v backendu. Toto omezení nevypínejte jako nahodilý pokus o opravu formuláře.
3. Oddělte chování prohlížeče od rozhodnutí serveru
V nástrojích pro vývojáře zkontrolujte, zda byl skript CAPTCHA načten, zda není chyba JavaScriptu a zda se při odeslání formuláře objeví token. Pokud se problém vyskytuje jen po určité volbě v panelu cookies, sledujte pořadí načítání skriptů a integraci souhlasů. Neměňte naslepo klasifikaci cookies jen proto, aby zmizela chybová hláška.
Poté zkontrolujte požadavek odesílaný do obchodu. Token musí dorazit do cesty, která provádí chráněnou akci. Skrytí tlačítka nebo kontrola pole pouze v JavaScriptu nenahrazuje serverovou kontrolu.
Google popisuje token odpovědi jako jednorázový a platný po dobu dvou minut. Dlouho otevřený formulář, opětovné odeslání stejného požadavku nebo dvě nezávislé validace jednoho tokenu proto mohou skončit odmítnutím. Po chybě je nutný správný nový pokus s novým tokenem. Podrobnosti a chybové kódy obsahuje dokumentace ověření odpovědi reCAPTCHA.
Ve v3 je absence checkboxu normální. Vyhodnocuje se výsledek a kontext akce. Práh by měl vycházet z pozorování skutečného provozu; výsledek testovací kopie nemusí odrážet chování produkce. Google popisuje samostatně bodové hodnocení i název akce. Při diagnostice zapisujte důvod odmítnutí, místo abyste při každé chybě automaticky snižovali práh.
4. Ověřte skutečný rozsah formulářů
Níže uvedená tabulka popisuje cesty nalezené v kódu reCAPTCHA Pro 1.4.9. Jde o informaci o integraci, nikoli o prohlášení správné funkčnosti každé šablony a každé verze jiných modulů.
Formuláře a podmínky vyžadující kontrolu
Místo
Co kód zahrnuje
Co je třeba potvrdit v obchodě
Registrace zákazníka
Vyhrazené validační hooky a obsluha formuláře v JavaScriptu.
Aktivní možnost registrace a provádění hooků v používaném formuláři.
Standardní contactform
Override kontrolující CAPTCHA před předáním správně vyplněného kontaktu k odeslání.
Zda se nasazený override provádí a zda kontakt neobsluhuje jiný modul.
Newsletter ps_emailsubscription
Hook, který může zastavit odeslání, a obsluha procesu potvrzení.
Napojení hooku a rozpoznání formuláře; potvrzení z e-mailu je samostatný krok.
TheCheckout
Samostatný přepínač a integrační kód.
Zda konečné potvrzení skutečně vyvolává validaci na straně serveru. Samotná přítomnost widgetu to nepotvrzuje.
Přihlášení, reset hesla, cizí formuláře
Netvoří výchozí seznam chráněných cest popsaný výše.
Existenci samostatné, ověřené integrace před tím, než bude formulář považován za zabezpečený.
5. Vlastní test: přijatá a odmítnutá odpověď
Provedli jsme kontrolovaný test nezměněného kódu reCAPTCHA Pro 1.4.9 a nasazeného override kontaktu. Odpověď služby jsme nahradili připravenými daty a funkci odeslání počítadlem volání. Ověřovali jsme rozhodnutí programu; neodesílali jsme zprávy, nepoužívali jsme tokeny zákazníků a neměřili jsme antispamovou účinnost Google.
Výsledky testu s kontrolovanými odpověďmi poskytovatele
Případ
Připravené podmínky
Pozorovaný výsledek
Správná odpověď kontaktu
Kladné success, action rovné contact, score 0,9 při prahu 0,5.
Jedno předání do náhradní funkce odeslání, bez chyby CAPTCHA.
Nesprávná odpověď kontaktu
Záporné success a kód invalid-input-response.
Bez předání k odeslání; chybová hláška.
Chybějící token
Veřejný klíč je nakonfigurován, token nebyl dodán.
Validátor odmítne před vyvoláním transportu.
Příliš nízké skóre v3
Score 0,1 při prahu 0,5.
Validátor odmítne.
Chybějící veřejný klíč
Neúplná konfigurace.
Validace je přeskočena; proto konfigurace vyžaduje samostatnou kontrolu.
Takový test umožňuje ověřit bránu v kódu. Úplné převzetí nasazení ještě vyžaduje projít skutečný formulář na kopii obchodu: s jeho šablonou, verzí PrestaShop, modulem formuláře a nastaveními. U externího checkoutu potvrďte zejména to, že odmítnutí backendu zastaví finální akci.
6. Myslete také na běžného uživatele
Po odmítnutí by měl formulář problém vysvětlit a umožnit nový pokus. Zkontrolujte chování po delší pauze, ztrátě sítě a chybě služby. Posuďte, zda si uživatel může ponechat zadaný obsah a zda tlačítko nezůstává trvale zablokované. To jsou kritéria převzetí konkrétního nasazení, nikoli automatická vlastnost každé sady modulů.
Pokud chráněná cesta funguje správně, ale problém se týká hromadného zatížení serveru nebo přímé pošty, zvolte ochranu pro tuto vrstvu. Limity požadavků, WAF a filtrování schránky vyžadují samostatná nastavení. CAPTCHA není zárukou odstranění všech botů.
Další krok: zkontrolujte rozsah reCAPTCHA Pro pro svůj formulář. Pokud nedokážete určit místo přerušení kontroly, využijte technickou podporu PrestaShop a uveďte URL, verze a anonymizovaný průběh testu.
Ověřeno 13.09.2026. Rozsah: zdroje modulu 1.4.9, kontrolované odpovědi validátoru a dokumentace Google. Ilustrace je redakční materiál, nikoli screenshot testovaného rozhraní.
Google reCAPTCHA Pro je moderní modul pro ochranu formulářů v PrestaShopu před spamem, boty a falešnými registracemi, navržený s ohledem na maximální účinnost a pohodlí uživatele. Podporuje reCAPTCHA v2, v3 a reCAPTCHA Enterprise (včetně režimů score-based a checkbox), takže snadno přizpůsobíte úroveň zabezpečení potřebám obchodu. Modul ověřuje captcha na...
Patryk Marek — majitel PrestaDev.pl a programátor specializující se na PrestaShop. Již mnoho let se zabývá tvorbou, rozvojem a údržbou internetových obchodů. Spojuje práci na kódu obchodu a modulů s konfigurací serverového prostředí, ve kterém tato řešení fungují.
Navrhuje a vyvíjí moduly PrestaShop, přizpůsobuje stávající funkce a připravuje integrace s velkoobchody a externími službami. Pracuje na importu a aktualizaci produktových dat, automatizaci správy katalogu, průběhu objednávky a nástrojích podporujících každodenní práci majitele obchodu.
Jeho zkušenosti zahrnují také aktualizace a migrace obchodů, diagnostiku chyb, analýzu výkonu a konfiguraci serverů a služeb potřebných pro fungování PrestaShopu. Při řešení problémů zohledňuje závislosti mezi moduly, šablonou, PHP, databází a nastavením hostingu.
Na blogu sdílí znalosti vyplývající z dlouholeté programátorské praxe a práce s technickým zázemím obchodů. Návody se zaměřují na konkrétní problémy, způsoby jejich ověření a omezení popisovaných řešení. Pomáhají majitelům obchodů i technickým pracovníkům připravit změny, posoudit jejich rozsah a ověřit výsledek.
Komentáře (0)