Здравствуйте, у нас возникла проблема с сайтом на вашей системе управления, а именно последнее время валит спам на сайте, хотя в форме обратной связи, от куда идет спам стоит капча, пробовали подключить капчу от гугл, но при попытке изменения кода сайт просто перестает загружаться, можете ли вы мне как-то помочь?

У меня на 2 сайтах началось то же самое. С конца декабря.

Разработчик поторопитесь ответить. Этот признак популярности движка раздражает. Как остановить спам?

Я думаю в файле AIMatrix_DDoS_inspector.php метод show_captcha если изменить чтобы каптчу рисовать подругому, на время спам прекратится.

Если изменить :=(

Василь вы предложите, не гадайте. Я программировать не умею. Мне заплатка нужна и объяснить куда ее.

Иначе день начинается с чистки почты. Не меньше палсотни "голые титьки смотреть тут без смс" каждый раз.

Василь, когда в исследованиях по нейронной схемотехнике лет 12 назад я показал пример, как простая схема на паре десятков нейрочипов вполне сносно распознаёт цифры с bitmap-картинки всего за несколько тактов обучения, тогда уже было понятно, что подобные идеи будут востребованы ботами, а изменение алгоритма рендеринга капчи подействует лишь до момента, пока оператор не покажет схеме как выглядят цифры в новой графике.

Так что написание иного алгоритма капчи в методе, который вы правильно назвали, оставим до лучших времён. Тем более что вся ваша работа затрётся очередным обновлением движка. Вместо этого существует способ, как навесить свою капча-логику на существующую обратную связь, вообще не влезая в файлы движка.

Как проходит запрос

Давайте вспомним порядок запуска компонентов Имперы во время обычного запроса страницы:

• первым делом запрос проходит через корневой .htaccess, где с помощью mod_Rewrite-правил происходит первичная маршрутизация для некоторых БАЗОВЫХ написаний URL-ов
  • все адреса маршрутизируются в единую стартовую точку - корневой файл index.php
  • базовые адреса тут же снабжаются GET-параметром module, где уже прописано имя связанного базового модуля
    • тут записаны схемы базовых адресов
    • если в запросе тоже имеется GET-параметр module, он имеет приоритет перед назначением базового
  • остальные снабжаются GET-параметром special_url, перекладывая определение модуля на компонент клиентской страницы
• второй шаг состоит в исполнении index.php - той самой единой стартовой точки
• третьим шагом происходит загрузка дефолтной модели "Клиентская Страница" - это упоминавшийся выше компонент клиентской страницы, в движке он представлен файлом objects/.def-models/ClientPage.php
  • вот тут и происходит запуск хелпера - это файл helper.php, если такой присутствует в текущем шаблоне
  • затем для небазовых адресов происходит определение связанного модуля (напомню, в случае базовых адресов - модуль уже известен)
  • затем выполняется загрузка модуля, если такой существует и не выключен в админпанели
    • если ещё в админке для такой страницы в поле Плагины: был прописан через запятую список подключаемых модулёчков, они подключаются подобно загрузке основного модуля в том же порядке как перечислены
      • то есть каждый плагин загружается только при его наличии и включенности
      • результирующий контент работы всякого плагина сохраняется в переменной $plugin_имяплагина, чтобы этот контент мог быть вывеен основным модулем, если потребуется
      • концепция плагина позволяет ему вместе с контентом вернуть ещё и сигнал FALSE, что расценивается как немедленное требование прекратить генерацию страницы, а ответом считать контент плагина + отправить код "Ошибка 404"
• четвёртый шаг передаёт управление загруженному модулю, чтобы тот подготовил контент центральной части страницы на основе tpl-файла, соответствующего этому модулю
• пятым шагом полученный контент центра страницы оборачивается в общий макет страницы - это файл index.tpl шаблона
  • оборачивание в общий макет отменяется для ajax-запросов и модулей, которые заявляют об этом специальным сигналом
• теперь результат отправляется в браузер пользователя

Таким образом уже на шаге 3, а именно когда запускается хелпер шаблона, нам доступно вклиниться в контроль параметров формы, прежде чем они дойдут до модуля обратной связи. Предполагая что вас атакуют спам-боты, работающие по предварительно сохранённому оттиску формы, мы можем сломать им оттиск тем, что всякий раз станем добавлять в форму случайный параметр, а на стороне хелпера шаблона будем проверять наличие такого параметра и отфутболивать любой пост без него.

Серверная сторона

Сначала добавим защитный код в хелпер шаблона вот так:

<?php
    class TemplateEmulator {
        ...

        public function __construct ( & $cms ) {
            $this->antispam($cms);
            ...
        }

        private function antispam ( & $cms ) {
            // внутреннее имя параметра
            $param = 'antispamFeedbackName';
            // если похоже что запостили фидбек
            if ($cms->request->existsPost('feedback_message')) {
                // но там нет нашего параметра
                $value = $cms->session->get($param);
                $test = $cms->request->getPost($param);
                if ($test === FALSE || $test !== $value) {
                    // тогда портим пост, например капчу
                    $_POST['captcha'] = '';
                    $_REQUEST['captcha'] = '';
                }
            }
            // выдумываем новый параметр
            $value = md5(uniqid());
            // запоминаем в сеансе, передаем в шаблон
            $cms->session->set($param, $value);
            $cms->smarty->assignByRef($param, $value);
        }

        ...
    }
?>

Принцип действия: если видим какой-то параметр, характерный для постинга формы обратной связи (например в POST-е присутствует поле feedback_message), тогда убеждаемся что там есть ещё и наш выдуманный параметр. В противном случае тут же портим какой-нибудь элемент POST-а, чтобы стартуемый за нами модуль обратной связи по-любому вернул пост на исправление ошибок ("вы не ввели капчу").

Клиентская сторона

Теперь добавим несколько строчек скрипта в конце файла index.tpl шаблона вот так:

<html>
    ...
    <body>
        ...
        <script>
            $('input[name="feedback_message"]').each(function () {
                var el = '<input name="{$antispamFeedbackName}" type="hidden">';
                $(this).closest('form').append(el);
            });
        </script>
    </body>
</html>

Если же ваш сайт построен по технологии NO-jQuery, вот альтернативный скрипт:

<html>
    ...
    <body>
        ...
        <script>
            (function () {
                var i, inp, el,
                    items = document.getElementsByName('feedback_message');
                for (i = 0; i <= items.length; i++) {
                    el = items[i];
                    while (el && 'parentNode' in el) {
                        el = el.parentNode;
                        if (el.tagName == 'FORM') {
                            inp = document.createElement('input');
                            inp.setAttribute('type', 'hidden');
                            inp.setAttribute('name', '{$antispamFeedbackName}');
                            el.appendChild(inp);
                            break;
                        }
                    }
                }
            }) ();
        </script>
    </body>
</html>

Оба скрипта выполняют то же действие со стороны браузера: найти в полученном с сервера документе все объекты с именем feedback_message и добавить в их родителськие формы скрытое поле с именем, содержащимся сейчас в переменной $antispamFeedbackName.

Такая защита моментально ограждает от автоматических ботов, даже если всякий раз те начнут снимать новый оттиск формы. Ведь кроме оттиска надо парсить ещё и яваскрипт в поисках нашего внедрения (но и его в принципе можем обфусцировать), чтобы установить, какой параметр собираются "на лету" добавить в форму. Кстати, эта защита бесполезна против ботов с эмулятором яваскрипта.

Благодарствую.

Тут еще Пара простейших защит от ботов. Предлагают тег формы вставлять скриптом. Чтоб бот типа не мог спарсить форму.