Jak zablokować spam formularzy PrestaShop: CAPTCHA i boty

Formularz kontaktowy co noc otrzymuje identyczne wiadomości, po angielsku, z linkiem. Rejestracje tworzą konta na nieprawdopodobne adresy, a newsletter zbiera adresy, które nigdy o nic nie prosiły. CAPTCHA jest jednak aktywna. Najczęściej chroni tylko wyświetlanie formularza: bot, który wysyła żądanie POST bezpośrednio do kontrolera, nigdy jej nie ładuje. Ten poradnik pokazuje, jak przenieść kontrolę na serwer, które formularze chronić, jak ustawić moduł bez utraty klientów i jak czytać to, co zostało odrzucone.

Dlaczego spam przechodzi, mimo że CAPTCHA jest aktywna?

Ponieważ CAPTCHA chroni wyświetlanie formularza, a nie jego przetwarzanie. Bot, który zna adres kontrolera, wysyła oczekiwane pola bezpośrednio do serwera, bez przeglądarki i bez widżetu.

Kontrolery kontaktu, rejestracji i newslettera są publiczne i łatwe do rozpoznania. Wystarczy poprawnie zbudowane żądanie POST: widżet nigdy się nie ładuje, token dostawcy nie jest pobierany, a wiadomość trafia do skrzynki. Dlatego sklepy nadal dostają spam, choć reCAPTCHA jest włączona.

Które formularze chroni moduł?

Moduł Antyspam formularzy: CAPTCHA i blokada botów chroni siedem natywnych formularzy PrestaShop: kontakt, tworzenie konta, logowanie, formularz klienta przy zamówieniu, zapomniane hasło, subskrypcję newslettera i opinie o produktach.

Po instalacji te siedem formularzy przechodzą w tryb Chroniony, bez zewnętrznej CAPTCHA. Strona Formularze pokazuje ich tryb, CAPTCHA, minimalny czas, limity, datę ostatniego zgłoszenia i stan Pola na stronie. Przycisk Edytuj otwiera ustawienia formularza; Chroń wszystko i Obserwuj wszystko zmieniają tryb całej listy.

Dla formularzy innych modułów są dwa rozwiązania. Reguła wskazuje kontroler, pole oznaczające zgłoszenie i oczekiwany format odpowiedzi; przycisk Dodaj regułę tworzy ją, do 20 reguł na sklep. Gotowa reguła obejmuje Powiadomienia o dostępności produktów (ps_emailalerts). Udokumentowane API PHP pozwala modułowi wywołać kontrole z własnego kodu.

Samo zamówienie nigdy nie jest filtrowane: ani koszyk, ani płatność, ani potwierdzenie, ani adresy. Strona tożsamości i etap resetowania hasła też nie są chronione.

Dla kogo jest ten moduł

• Dla sklepu, który dostaje spam na kontakcie, rejestracji lub newsletterze, mimo zainstalowanej CAPTCHA.
• Dla sklepu, który chce widzieć, co i dlaczego zostało odrzucone, zamiast odkrywać szkody w skrzynce.
• Dla agencji prowadzącej kilka sklepów, która chce ustawić ochronę osobno w każdym z nich.

Dla kogo nie jest

• Dla sklepu bez wystawionego formularza: nie byłoby czego chronić.
• Dla sprzedawcy szukającego zapory aplikacyjnej lub ochrony przed atakami odmowy usługi: to nie jest rola tego modułu.
• Dla sprzedawcy oczekującego zera spamu: żaden moduł tego nie obiecuje, a człowiek może poprawnie wypełnić formularz.

Jak zainstalować i ustawić ochronę krok po kroku?

Zainstaluj moduł, aktywuj licencję, zostaw najpierw wszystkie formularze w obserwacji, a po przeczytaniu dziennika włącz ochronę formularz po formularzu.

1. Sprawdź wymagania: PrestaShop 1.7.8, 8.0+ lub 9.0+, PHP 7.4 lub nowszy.
2. Zainstaluj archiwum z menedżera modułów. Siedem natywnych formularzy powstaje dla każdego sklepu, dodawana jest lista domen jednorazowych i tworzone są tabele modułu.
3. Otwórz Konfiguruj i aktywuj licencję WePresta. Dopóki licencja nie jest ważna, moduł pozostaje wyłączony, a formularze nie są sprawdzane.
4. Zaplanuj codzienne zadanie konserwacji, z adresem podanym w konfiguracji lub dostarczoną linią poleceń. Czyści dziennik, liczniki, wygasłe blokady i pozostałe przeterminowane dane.
5. Otwórz Formularze i kliknij Obserwuj wszystko. Wszystkie kontrole się wykonują, nic nie jest odrzucane, a dziennik zapisuje to, co zostałoby zablokowane.
6. Poczekaj kilka dni, potem otwórz Dziennik zablokowanych prób i Pulpit. Powody pokazują, czy blokada dotknęłaby botów, czy klientów, zwłaszcza za adresem współdzielonym przez firmę lub operatora komórkowego.
7. Uruchom Przetestuj moją ochronę. Narzędzie czyta stronę formularza jak odwiedzający, sprawdza pola, token i skrypt, wysyła bezpośrednie zgłoszenie bez pól, aby sprawdzić, że zostałoby odrzucone, i sprawdza klucze wybranego dostawcy.
8. Włącz ochronę przyciskiem Chroń wszystko albo formularz po formularzu, zaczynając od kontaktu i newslettera, potem rejestracji, logowania i opinii. Formularz klienta przy zamówieniu zostaw z szerokimi limitami i bez minimalnego czasu.
9. Dodaj CAPTCHA tylko wtedy, gdy formularz nadal jest celem, po wpisaniu kluczy i sprawdzeniu przycisku Test. Adresy partnerów i narzędzi monitorujących umieść na liście dozwolonych, zanim zaostrzysz limity.

Moduł nie zapisuje żadnego pliku motywu: Classic i Hummingbird działają bez zmian. Uprawnienia pracowników dzielą się na przeglądanie, zarządzanie i dane, sprawdzane po stronie serwera. Dokumentacja opisuje każde ustawienie, także zachowanie, gdy dostawca nie odpowiada.

Jak czytać dziennik i reagować na odmowę?

Dla każdej próby dziennik podaje formularz, wynik, powód, datę, zamaskowany adres i domenę e-mail, a także działania dostępne w wierszu.

Powody są jednoznaczne: Pole-pułapka wypełnione, Wysłano zbyt szybko, Brak pól ochrony, Zbyt wiele zgłoszeń z tego adresu, CAPTCHA nieudana, Adres na liście blokowanych, E-mail na liście blokowanych, Domena e-mail nie może odbierać wiadomości. Każdy wiersz pozwala zablokować adres lub jego zakres, dopuścić adres, zablokować domenę e-mail albo zdjąć blokadę. Dziennik możesz wyeksportować do CSV i wyczyścić.

Pulpit daje obraz całości: Przyjęte, Zablokowane, Wskaźnik blokad, Zostałoby zablokowane, Przyjęte bez kontroli i Zwolnione, z wykresem 30 dni i szczegółami według formularza i powodu. Skok na jednym formularzu widać od razu.

Przechowywanie wynosi domyślnie 30 dni i ustawia się je w Rejestr i prywatność. Adres nie jest zapisywany jawnie: jest maskowany, a skrót służy listom i limitom. Zachowana jest domena e-mail, nigdy pełny adres.

Konkretny przypadek: formularz kontaktowy zalany w nocy

Formularz kontaktowy co noc otrzymuje kilkanaście identycznych wiadomości. Dziennik pokazuje Pole-pułapka wypełnione na tym samym zakresie adresów. Blokujesz zakres jednym kliknięciem z wiersza, a następnego dnia sprawdzasz, czy zgłoszenia klientów nadal przechodzą. Jeśli zatrzymana zostanie prawdziwa wiadomość, lista dozwolonych ją przywraca bez wyłączania ochrony.

Czy potrzebna jest zewnętrzna CAPTCHA i którą wybrać?

Nie domyślnie: kontrole po stronie serwera działają bez klucza i konta zewnętrznego, a CAPTCHA dodaje się tylko do formularza, który nadal jest celem.

Gdy jej chcesz, wybór odbywa się formularz po formularzu: Google reCAPTCHA v2 z polem wyboru lub niewidoczna, reCAPTCHA v3 z progiem wyniku, Cloudflare Turnstile, hCaptcha w wersji normalnej, kompaktowej lub niewidocznej albo Friendly Captcha. Klucze wpisujesz w Konfiguruj; moduł nigdy ich nie pokazuje, a przycisk Test sprawdza, czy są akceptowane i czy domena jest dozwolona.

Domyślnie skrypt dostawcy ładuje się tylko na stronach z formularzem chronionym przez tego dostawcę, przy pierwszym kontakcie z formularzem. Strona bez formularza nic nie ładuje. Jeśli dostawca nie odpowiada, wybierasz, czy zgłoszenie przechodzi, zapisane jako niesprawdzone, czy zostaje odrzucone.

Zgoda też jest ustawieniem: skrypt może czekać na zgodę odwiedzającego, z modułem Cookies RODO lub innym narzędziem zgód. Bez zgody formularz pozostaje chroniony przez kontrole natywne albo pokazuje komunikat, jeśli wybrano pytanie o zgodę.

Zewnętrzna CAPTCHA ma własne warunki i własną politykę prywatności. To Ty musisz wspomnieć o niej w swojej polityce i wybrać właściwą zgodę; moduł nie certyfikuje zgodności z RODO.

Co robi moduł i jakie ma ograniczenia?

Moduł ogranicza automatyczne zgłoszenia i dokumentuje każdą odmowę, ale nie obiecuje zera spamu i nie zastępuje zapory ani porady prawnej.

• Brak obietnicy wyniku. Człowiek może poprawnie wypełnić formularz. Moduł czyni automatyczne zgłoszenia kosztownymi i widocznymi; nie usuwa ich wszystkich.
• Zamówienie zostaje poza filtrem. Koszyk, płatność, potwierdzenie i adresy nie są sprawdzane. Formularz klienta przy zamówieniu zachowuje szerokie limity.
• Odwiedzający dzielą adresy. Zbyt surowy limit może zaszkodzić firmie lub operatorowi komórkowemu. Tryb obserwacji i lista dozwolonych pozwalają sprawdzić przed zaostrzeniem.
• Brak certyfikacji RODO. Moduł pomaga ograniczyć zbierane dane i daje hooki eksportu i usuwania, ale nie zastępuje polityki prywatności ani porady prawnej.
• Ważna licencja. Bez ważnej licencji moduł się wyłącza: formularze nie są sprawdzane, CAPTCHA nie jest pokazywana i nic nie trafia do dziennika. Ustawienia, listy i dziennik zostają.
• Połączenia sieciowe. Weryfikacja CAPTCHA, kontrola MX i sprawdzanie robotów wyszukiwarek korzystają z połączeń wychodzących; jeśli dostawca CAPTCHA nie odpowiada, obowiązuje wybrane zachowanie, a nieudane zapytanie DNS nigdy nie odrzuca zgłoszenia.

W sklepie wielosklepowym ustawienia, formularze, dziennik i statystyki pozostają osobne dla każdego sklepu, a wpisy list mogą być współdzielone. Jeśli formularz kontaktowy pochodzi z innego modułu, karta dynamicznego formularza kontaktowego pokazuje typowy przypadek; dla ogólnego bezpieczeństwa sklepu audyt bezpieczeństwa uzupełnia ochronę formularzy.