Jeżeli spam przechodzi mimo CAPTCHA, najpierw sprawdź, czy serwer weryfikuje zgłoszenie z tego konkretnego formularza. Widoczny checkbox, plakietka reCAPTCHA lub aktywny moduł nie wystarczą. Ochrona musi objąć zarówno wygenerowanie tokenu w przeglądarce, jak i decyzję serwera przed utworzeniem konta, zapisaniem subskrypcji czy wysłaniem wiadomości.
Ten poradnik jest dla właścicieli sklepów PrestaShop i osób odpowiedzialnych za ich obsługę techniczną. Pomaga ustalić źródło problemu oraz przygotować sprawdzalną próbę. Nie zakłada, że każdy przypadek wymaga wymiany modułu.
1. Ustal, którędy naprawdę przychodzi spam
Zacznij od jednego przykładu: godziny zgłoszenia, rodzaju zdarzenia i formularza, z którym je wiążesz. Nie publikuj adresu klienta, treści prywatnej korespondencji ani pełnego żądania zawierającego tokeny. W zgłoszeniu do programisty wystarczą zanonimizowane dane i instrukcja odtworzenia problemu.
Wiadomość w skrzynce sklepu mogła pochodzić ze standardowego kontaktu, formularza na karcie produktu, modułu opinii albo bezpośrednio z poczty. Ochrona formularza kontaktowego nie filtruje automatycznie wiadomości wysyłanych na publiczny adres e-mail. Podobnie CAPTCHA przy zakładaniu konta nie zabezpiecza z definicji zapisu do newslettera.
Zapisz dokładny URL i nazwę modułu obsługującego formularz.
Ustal, czy problem występuje dla gościa, klienta zalogowanego czy obu grup.
Odtwórz zgłoszenie na komputerze i telefonie, jeśli formularze różnią się układem.
Sprawdź, czy formularz jest wysyłany klasycznie, przez AJAX czy przez zewnętrzny checkout.
Dopiero z takim opisem porównuj zakres reCAPTCHA Pro dla PrestaShop z rzeczywistym miejscem problemu. Ogólne stwierdzenie „CAPTCHA jest włączona na stronie” nie pozwala ocenić skuteczności konkretnej ścieżki.
2. Sprawdź typ klucza, domenę i kompletną konfigurację
Klucz v2, v3 i konfiguracja Enterprise należą do różnych trybów. Ustawiony w module rodzaj weryfikacji musi odpowiadać konfiguracji usługi. Sprawdź też domenę, z której korzysta klient: kopia testowa, domena produkcyjna i dodatkowy host nie muszą mieć tych samych uprawnień.
W przejrzanej wersji reCAPTCHA Pro 1.4.9 pusty publiczny klucz powoduje pominięcie centralnej walidacji. Zainstalowany moduł i zaznaczony przełącznik nie są więc dowodem kompletnego uruchomienia ochrony. Sprawdź, czy wymagane pola wybranego trybu są rzeczywiście uzupełnione; klucza prywatnego nie umieszczaj w zrzutach ekranu ani w kodzie strony.
Ograniczenia domen ustawiaj po stronie Google. Przejrzany kod modułu nie wykonuje dodatkowego porównania pola hostname w odpowiedzi. Dokumentacja Google dotycząca domen wyjaśnia, że wyłączenie ich weryfikacji wymaga samodzielnej kontroli hosta w backendzie. Nie wyłączaj tego ograniczenia jako przypadkowej próby naprawy formularza.
3. Rozdziel działanie przeglądarki od decyzji serwera
W narzędziach deweloperskich sprawdź, czy skrypt CAPTCHA został pobrany, czy nie ma błędu JavaScript i czy przy wysłaniu formularza pojawia się token. Jeśli problem występuje tylko po określonej decyzji w panelu cookies, prześledź kolejność ładowania skryptów i integrację zgód. Nie zmieniaj w ciemno klasyfikacji cookies tylko po to, aby zniknął komunikat błędu.
Następnie sprawdź żądanie wysyłane do sklepu. Token powinien dotrzeć do ścieżki, która wykonuje chronioną czynność. Ukrycie przycisku lub sprawdzenie pola wyłącznie w JavaScript nie zastępuje kontroli serwerowej.
Google opisuje token odpowiedzi jako jednorazowy i ważny przez dwie minuty. Długo otwarty formularz, ponowna wysyłka tego samego żądania albo dwie niezależne walidacje jednego tokenu mogą zatem zakończyć się odmową. Po błędzie potrzebna jest prawidłowa ponowna próba z nowym tokenem. Szczegóły i kody błędów zawiera dokumentacja weryfikacji odpowiedzi reCAPTCHA.
W v3 brak checkboxa jest normalny. Ocenia się wynik oraz kontekst działania. Próg powinien wynikać z obserwacji właściwego ruchu; wynik kopii testowej nie musi odzwierciedlać zachowania produkcji. Google opisuje osobno wynik punktowy i nazwę działania. W diagnozie zapisuj przyczynę odmowy, zamiast automatycznie obniżać próg przy każdym błędzie.
4. Zweryfikuj rzeczywisty zakres formularzy
Poniższa tabela opisuje ścieżki znalezione w kodzie reCAPTCHA Pro 1.4.9. Jest informacją o integracji, a nie deklaracją poprawnego działania każdego motywu i każdej wersji innych modułów.
Formularze i warunki wymagające sprawdzenia
Miejsce
Co obejmuje kod
Co trzeba potwierdzić w sklepie
Rejestracja klienta
Dedykowane hooki walidacji i obsługa formularza w JavaScript.
Aktywną opcję rejestracji oraz wykonanie hooków w używanym formularzu.
Standardowy contactform
Override sprawdzający CAPTCHA przed przekazaniem poprawnie wypełnionego kontaktu do wysyłki.
Czy wdrożony override jest wykonywany, a kontaktu nie obsługuje inny moduł.
Newsletter ps_emailsubscription
Hook mogący zatrzymać zgłoszenie oraz obsługę procesu potwierdzenia.
Powiązanie hooka i rozpoznawanie formularza; potwierdzenie z e-maila to osobny krok.
TheCheckout
Osobny przełącznik oraz kod integracyjny.
Czy końcowe potwierdzenie faktycznie wywołuje walidację po stronie serwera. Sama obecność widgetu tego nie potwierdza.
Logowanie, reset hasła, obce formularze
Nie stanowią domyślnej listy chronionych ścieżek opisanej powyżej.
Istnienie odrębnej, sprawdzonej integracji przed uznaniem formularza za zabezpieczony.
5. Własna próba: zaakceptowana i odrzucona odpowiedź
Przeprowadziliśmy kontrolowaną próbę niezmienionego kodu reCAPTCHA Pro 1.4.9 i wdrożonego override kontaktu. Odpowiedź usługi zastąpiliśmy przygotowanymi danymi, a funkcję wysyłki licznikiem wywołań. Sprawdzaliśmy decyzję programu; nie wysyłaliśmy wiadomości, nie używaliśmy tokenów klientów i nie mierzyliśmy skuteczności antyspamowej Google.
Wyniki próby z kontrolowanymi odpowiedziami dostawcy
Przypadek
Przygotowane warunki
Zaobserwowany wynik
Poprawna odpowiedź kontaktu
Dodatnie success, action równe contact, score 0,9 przy progu 0,5.
Jedno przekazanie do zastępczej funkcji wysyłki, bez błędu CAPTCHA.
Niepoprawna odpowiedź kontaktu
Ujemne success i kod invalid-input-response.
Brak przekazania do wysyłki; komunikat błędu.
Brak tokenu
Publiczny klucz jest skonfigurowany, tokenu nie dostarczono.
Walidator odmawia przed wywołaniem transportu.
Zbyt niski wynik v3
Score 0,1 przy progu 0,5.
Walidator odmawia.
Brak publicznego klucza
Niekompletna konfiguracja.
Walidacja zostaje pominięta; dlatego konfiguracja wymaga osobnej kontroli.
Taka próba pozwala sprawdzić bramkę w kodzie. Pełny odbiór wdrożenia wymaga jeszcze przejścia przez rzeczywisty formularz na kopii sklepu: z jego motywem, wersją PrestaShop, modułem formularza i ustawieniami. Dla zewnętrznego checkoutu potwierdź szczególnie, że odmowa backendu zatrzymuje końcową czynność.
6. Zadbaj również o normalnego użytkownika
Po odrzuceniu formularz powinien wyjaśnić problem i umożliwić ponowną próbę. Sprawdź zachowanie po dłuższej przerwie, utracie sieci i błędzie usługi. Oceń, czy użytkownik może zachować wpisaną treść i czy przycisk nie pozostaje trwale zablokowany. To kryteria odbioru konkretnego wdrożenia, nie automatyczna cecha każdego zestawu modułów.
Jeśli chroniona ścieżka działa poprawnie, a problem dotyczy masowego obciążenia serwera lub bezpośredniej poczty, dobierz ochronę do tej warstwy. Limity żądań, WAF i filtrowanie skrzynki wymagają osobnych ustawień. CAPTCHA nie jest gwarancją eliminacji wszystkich botów.
Następny krok: sprawdź zakres reCAPTCHA Pro dla swojego formularza. Jeśli nie potrafisz wskazać miejsca przerwania kontroli, skorzystaj z pomocy technicznej PrestaShop, podając URL, wersje i zanonimizowany przebieg próby.
Sprawdzono 13.09.2026. Zakres: źródła modułu 1.4.9, kontrolowane odpowiedzi walidatora i dokumentacja Google. Ilustracja jest materiałem redakcyjnym, nie zrzutem testowanego interfejsu.
Google reCAPTCHA Pro to nowoczesny moduł do ochrony formularzy w PrestaShop przed spamem, botami i fałszywymi rejestracjami, zaprojektowany z myślą o maksymalnej skuteczności i wygodzie użytkownika. Obsługuje reCAPTCHA v2, v3 oraz reCAPTCHA Enterprise (w tym tryby score-based i checkbox), dzięki czemu łatwo dopasujesz poziom zabezpieczeń do potrzeb...
Patryk Marek — właściciel PrestaDev.pl i programista specjalizujący się w PrestaShop. Od wielu lat zajmuje się tworzeniem, rozwojem i utrzymaniem sklepów internetowych. Łączy pracę nad kodem sklepu i modułów z konfiguracją środowiska serwerowego, w którym te rozwiązania działają.
Projektuje i rozwija moduły PrestaShop, dostosowuje istniejące funkcje oraz przygotowuje integracje z hurtowniami i usługami zewnętrznymi. Pracuje nad importem i aktualizacją danych produktów, automatyzacją obsługi katalogu, przebiegiem zamówienia oraz narzędziami wspierającymi codzienną pracę właściciela sklepu.
Jego doświadczenie obejmuje również aktualizacje i migracje sklepów, diagnozowanie błędów, analizę wydajności oraz konfigurację serwerów i usług potrzebnych do działania PrestaShop. Przy rozwiązywaniu problemów uwzględnia zależności między modułami, motywem, PHP, bazą danych i ustawieniami hostingu.
Na blogu dzieli się wiedzą wynikającą z wieloletniej praktyki programistycznej i pracy z zapleczem technicznym sklepów. Poradniki skupiają się na konkretnych problemach, sposobach ich sprawdzenia i ograniczeniach opisywanych rozwiązań. Pomagają właścicielom sklepów oraz osobom technicznym przygotować zmiany, ocenić ich zakres i zweryfikować rezultat.
Komentarze (0)