Якщо спам проходить попри CAPTCHA, спочатку перевірте, чи сервер верифікує надсилання саме з цієї конкретної форми. Видимий прапорець, бейдж reCAPTCHA або активний модуль недостатні. Захист має охоплювати як генерацію токена в браузері, так і рішення сервера перед створенням облікового запису, збереженням підписки чи надсиланням повідомлення.
Цей посібник призначений для власників магазинів PrestaShop і осіб, відповідальних за їх технічне обслуговування. Він допомагає визначити джерело проблеми та підготувати перевірюваний тест. Він не передбачає, що кожен випадок потребує заміни модуля.
1. Визначте, яким шляхом насправді надходить спам
Почніть з одного прикладу: часу надсилання, типу події та форми, з якою ви це пов’язуєте. Не публікуйте адресу клієнта, зміст приватного листування чи повний запит, що містить токени. У зверненні до розробника достатньо анонімізованих даних та інструкції з відтворення проблеми.
Повідомлення в поштовій скриньці магазину могло надійти зі стандартної контактної форми, форми на картці товару, модуля відгуків або безпосередньо з пошти. Захист контактної форми не фільтрує автоматично повідомлення, надіслані на публічну адресу e-mail. Так само CAPTCHA під час створення облікового запису за замовчуванням не захищає підписку на розсилку.
Запишіть точний URL і назву модуля, який обслуговує форму.
Визначте, чи проблема виникає для гостя, авторизованого клієнта чи для обох груп.
Відтворіть надсилання на комп’ютері та телефоні, якщо форми відрізняються за макетом.
Перевірте, чи форма надсилається класично, через AJAX чи через зовнішній checkout.
Лише з таким описом порівнюйте охоплення reCAPTCHA Pro для PrestaShop з фактичним місцем проблеми. Загальне твердження «CAPTCHA увімкнена на сайті» не дає змоги оцінити ефективність конкретного шляху.
2. Перевірте тип ключа, домен і повну конфігурацію
Ключ v2, v3 і конфігурація Enterprise належать до різних режимів. Тип верифікації, встановлений у модулі, має відповідати конфігурації сервісу. Також перевірте домен, яким користується клієнт: тестова копія, продукційний домен і додатковий хост не обов’язково мають однакові дозволи.
У перевіреній версії reCAPTCHA Pro 1.4.9 порожній публічний ключ спричиняє пропуск центральної валідації. Тому встановлений модуль і позначений перемикач не є доказом повного запуску захисту. Перевірте, чи обов’язкові поля вибраного режиму справді заповнені; приватний ключ не розміщуйте на скриншотах або в коді сторінки.
Обмеження доменів налаштовуйте на боці Google. Перевірений код модуля не виконує додаткового порівняння поля hostname у відповіді. Документація Google щодо доменів пояснює, що вимкнення їх верифікації потребує самостійного контролю хоста в backend. Не вимикайте це обмеження як випадкову спробу виправити форму.
3. Розділіть роботу браузера і рішення сервера
В інструментах розробника перевірте, чи завантажився скрипт CAPTCHA, чи немає помилки JavaScript і чи з’являється токен під час надсилання форми. Якщо проблема виникає лише після певного рішення в панелі cookies, простежте порядок завантаження скриптів та інтеграцію згод. Не змінюйте навмання класифікацію cookies лише для того, щоб зникло повідомлення про помилку.
Далі перевірте запит, що надсилається до магазину. Токен має дійти до шляху, який виконує захищену дію. Приховування кнопки або перевірка поля лише в JavaScript не замінює серверного контролю.
Google описує токен відповіді як одноразовий і дійсний протягом двох хвилин. Тому форма, відкрита надто довго, повторне надсилання того самого запиту або дві незалежні валідації одного токена можуть завершитися відмовою. Після помилки потрібна коректна повторна спроба з новим токеном. Деталі та коди помилок містить документація з верифікації відповіді reCAPTCHA.
У v3 відсутність прапорця є нормальною. Оцінюється результат і контекст дії. Поріг має випливати зі спостереження за реальним трафіком; результат тестової копії не обов’язково відображає поведінку продукції. Google окремо описує бальну оцінку та назву дії. Під час діагностики фіксуйте причину відмови, замість того щоб автоматично знижувати поріг при кожній помилці.
4. Перевірте фактичне охоплення форм
Наведена нижче таблиця описує шляхи, знайдені в коді reCAPTCHA Pro 1.4.9. Це інформація про інтеграцію, а не декларація коректної роботи кожної теми та кожної версії інших модулів.
Форми та умови, які потрібно перевірити
Місце
Що охоплює код
Що потрібно підтвердити в магазині
Реєстрація клієнта
Спеціальні хуки валідації та обробка форми в JavaScript.
Активну опцію реєстрації та виконання хуків у використовуваній формі.
Стандартний contactform
Override, що перевіряє CAPTCHA перед передачею коректно заповненої контактної форми на надсилання.
Чи виконується впроваджений override і чи контакт не обслуговується іншим модулем.
Розсилка ps_emailsubscription
Хук, який може зупинити надсилання, а також обробку процесу підтвердження.
Прив’язку хука та розпізнавання форми; підтвердження з e-mail — це окремий крок.
TheCheckout
Окремий перемикач і код інтеграції.
Чи фінальне підтвердження справді викликає валідацію на боці сервера. Сама наявність віджета цього не підтверджує.
Вхід, скидання пароля, сторонні форми
Не входять до стандартного списку захищених шляхів, описаного вище.
Наявність окремої, перевіреної інтеграції перед тим, як вважати форму захищеною.
5. Власний тест: прийнята та відхилена відповідь
Ми провели контрольований тест незміненого коду reCAPTCHA Pro 1.4.9 і впровадженого override контактної форми. Відповідь сервісу ми замінили підготовленими даними, а функцію надсилання — лічильником викликів. Ми перевіряли рішення програми; не надсилали повідомлень, не використовували токени клієнтів і не вимірювали антиспам-ефективність Google.
Результати тесту з контрольованими відповідями постачальника
Випадок
Підготовлені умови
Спостережуваний результат
Коректна відповідь контактної форми
Додатне success, action дорівнює contact, score 0,9 при порозі 0,5.
Одна передача до замінної функції надсилання, без помилки CAPTCHA.
Некоректна відповідь контактної форми
Від’ємне success і код invalid-input-response.
Передачі на надсилання немає; повідомлення про помилку.
Відсутність токена
Публічний ключ налаштований, токен не надано.
Валідатор відмовляє до виклику транспорту.
Надто низький результат v3
Score 0,1 при порозі 0,5.
Валідатор відмовляє.
Відсутність публічного ключа
Неповна конфігурація.
Валідація пропускається; тому конфігурація потребує окремого контролю.
Такий тест дає змогу перевірити шлюз у коді. Повне приймання впровадження ще потребує проходження через реальну форму на копії магазину: з її темою, версією PrestaShop, модулем форми та налаштуваннями. Для зовнішнього checkout особливо підтвердьте, що відмова backend зупиняє фінальну дію.
6. Подбайте також про звичайного користувача
Після відхилення форма має пояснити проблему та дати змогу повторити спробу. Перевірте поведінку після довшої перерви, втрати мережі та помилки сервісу. Оцініть, чи може користувач зберегти введений текст і чи кнопка не залишається заблокованою назавжди. Це критерії приймання конкретного впровадження, а не автоматична властивість кожного набору модулів.
Якщо захищений шлях працює коректно, а проблема стосується масового навантаження на сервер або прямої пошти, підберіть захист для цього рівня. Ліміти запитів, WAF і фільтрація поштової скриньки потребують окремих налаштувань. CAPTCHA не є гарантією усунення всіх ботів.
Наступний крок: перевірте охоплення reCAPTCHA Pro для вашої форми. Якщо ви не можете вказати місце переривання контролю, скористайтеся технічною підтримкою PrestaShop, вказавши URL, версії та анонімізований перебіг тесту.
Перевірено 13.09.2026. Обсяг: джерела модуля 1.4.9, контрольовані відповіді валідатора та документація Google. Ілюстрація є редакційним матеріалом, а не скриншотом протестованого інтерфейсу.
Google reCAPTCHA Pro — це сучасний модуль для захисту форм у PrestaShop від спаму, ботів і фальшивих реєстрацій, розроблений з урахуванням максимальної ефективності та зручності для користувача. Підтримує reCAPTCHA v2, v3 та reCAPTCHA Enterprise (зокрема режими score-based і checkbox), завдяки чому ви легко налаштуєте рівень захисту відповідно до потреб...
Патрик Марек — власник PrestaDev.pl і програміст, який спеціалізується на PrestaShop. Уже багато років займається створенням, розвитком і підтримкою інтернет-магазинів. Поєднує роботу над кодом магазину та модулів із налаштуванням серверного середовища, у якому працюють ці рішення.
Проєктує та розвиває модулі PrestaShop, адаптує наявні функції, а також готує інтеграції з оптовими складами та зовнішніми сервісами. Працює над імпортом і оновленням даних про товари, автоматизацією обслуговування каталогу, процесом оформлення замовлення та інструментами, що підтримують щоденну роботу власника магазину.
Його досвід також охоплює оновлення та міграції магазинів, діагностику помилок, аналіз продуктивності, а також налаштування серверів і сервісів, необхідних для роботи PrestaShop. Під час розв’язання проблем враховує залежності між модулями, темою, PHP, базою даних і налаштуваннями хостингу.
У блозі ділиться знаннями, що випливають із багаторічної програмістської практики та роботи з технічним бекендом магазинів. Посібники зосереджені на конкретних проблемах, способах їх перевірки та обмеженнях описаних рішень. Вони допомагають власникам магазинів і технічним спеціалістам підготувати зміни, оцінити їх обсяг і перевірити результат.
Коментарі (0)