Как защититься от создания пустых заказов ботами?

Question

[photosho]

Каким образом боты могут создавать пустые заказы (без товарных позиций) в Bitrix? Установлено решение Aspro, также, установлен модуль ReCaptcha, но он ситуацию не решает. Возможно, это обращение к какому-то внутреннему ajax-скрипту?

Comments

[Adamos]

Момент создания заказа известен.
Смотрим в логи веб-сервера, на какие адреса в этот момент обращались с POST-запросом и выясняем, где именно Битрикс оказывает медвежью услугу. Блокируем этот скрипт на хрен, если все равно все работает через стороннее решение.

[koder_1]

Adamos, Сторонние решения создают заказы через обычный механизм заказов Битрикс.
А метод решения посмотреть к каким скриптам обращались, рабочий.

[Adamos]

koder_1, механизм может быть использованием классов Битрикса, но не конкретных (традиционно дырявых) скриптов. Например, у меня на подопечном Битриксе тупо забанены в htaccess скрипты redirect.php, html_editor_action.php и т.п., что не мешает сайту нормально работать.
Магазин на том сайте я сделал, тщательно избегая решений Битрикса в интерфейсе, только аякс и только через свои точки входа. Зато уверен, что все триста тысяч заказов - от живых ;)

[koder_1]

Adamos, Оформление заказа в ЛЮБОМ решении Битрикс совершенно точно сделано
на стандартном компоненте Битрикс оформление заказа, иначе будет не подключить модули оплаты и доставки и будут проблемы с интеграциями с црм, с 1с.

redirect.php блокировать имеет смысл, но только по запросу от внешних серверов.

Если вы тщательно избегаете решений Битрикс в интерфейсе, пилите уж сразу собственные интерфейсы на любом сайте, чего уж мелочиться.

[Adamos]

koder_1, да я так и делаю. Битрикс у меня - легаси 15-летней настойки, его просто тяжко переписать целиком на что-нибудь вменяемое. Приходится подпирать.

[koder_1]

Adamos, Ну то-есть, вместо того, чтоб сделать сайт за 2 месяца, у Вас растянется на полгода, а поддерживать этот код не сможет ни Битрикс программист, ни какой-либо иной? Отличный подход.

[Adamos]

koder_1, когда делается нетиповой сайт - типовые решения только мешают. Особенно такие кондовые, негибкие и неприспособляемые, как у Битрикса. Можете даже не начинать холивар.

[koder_1]

Я с Битриксом работаю давно.
Не помню ни одного на столько нетипового сайта, чтоб мне не удалось сделать стандартными средствами Битрикс.
Вот делал магазин с корзиной как на озоне, удалось сделать стандартными компонентами Битрикс с небольшой допиской.
Если прямо нужно совсем не стандартное оформление заказа, его можно сделать стандартным api битрикса для оформления заказа, свои классы писать не нужно.

[Adamos]

koder_1, на упомянутом сайте продаются три принципиально разных вида электронных товаров, один каталог реальных и еще один - фьючерсных. Товаров тысячи, но они мелкие и дешевые, по одному (во всяком случае, с доставкой) обычно не продаются, при этом имеют строгую иерархию, так что выводить каждый товар отдельной карточкой нет смысла вовсе... да я бы свихнулся дрочить вприсядку с битриксовскими компонентами, да еще в то время, когда D7 еще и не задумывалось.
Написал свои интерфейсы, не делающие голову клиенту и наглядно позволяющие ему получить то, что он хочет и принести фирме деньги. На бэке обработал эту логику в кошмарные таблицы Битрикса о семьдесят полей. Добавляя свои таблицы с информацией, которая в предусмотренное Битриксом не вписывалась. И оно таки пятнадцать лет работает.
А я больше с Битриксом не связываюсь и живу душа в душу с Ларавелью. Делая на ней именно то, что нужно мне, а не то, что придумали пятьдесят маркетоидов и полтора программиста.
Черт, холивар все-таки получился ;)

[koder_1]

Adamos, Под такую задачу, как описали, имеет смысл делать что-то сильно кастомное, это разумно. Каталог со стороны клиента можно вывести не компонентами, а таки с помощью api Битрикс.
Админку можно сделать свою кастомную.
Функции добавления в корзину взять можно из api битрикс.
Добавлять что-то своё в таблицы битрикс - возможно не стоило.
Там ведь можно добавлять товар в корзину с пользовательскими свойствами,
в заказе есть служебные поля, было ли это в Битриксе 15 лет назад, не знаю.
В современном Битриксе, вероятно добавлять свои поля в таблицы битрикс бы не пришлось.
А поддерживать такой проект другому человеку, хоть вы его сделаете идеально и на идеальном движке было б тяжко в любом случае.

Верю, что под такую задачу ваш подход таки был оправдан.

[Adamos]

koder_1, в Битрикс все добавлялось через функции Битрикса, конечно, а не напрямую в таблицы. Правда, был однажды сюрприз с внезапно после обновления переставшим работать методом COrder::SetPaid... после чего перестал надеяться на официальную техподдержку.
Ну, и я уверен, что мои пару компактных таблиц с фьючерсами (которые на момент заказа еще тупо отсутствуют в каталоге) поддерживать намного проще и удобнее, чем тот колхоз, который ради этого пришлось бы наворотить в кастомных полях заказа по-битриксовски. И для последующей работы с этими данными все равно штатные интерфейсы Битрикса не годятся, необходимости завязываться на него - никакой.

Answer 1

[Михаил Ливач]

повесьте обработчик на событие onOrderAdd и записывайте в какой-то лог всё, что нужно: $_SERVER['REQUEST_METHOD'], $_SERVER['REQUEST_URI'], что-нибудь ещё

Answer 2

[itauditmedia]

photosho какое именно решение Аспро используется?
создается "заказ" или "быстрый заказ" из карточки товара?
скорее всего "быстрый" - тогда искомый вам компонент быстрого заказа вызывается тут www/ajax/one_click_buy.php
проверяйте $_REQUEST['ELEMENT_ID'] - что его значение - действительно элемент ИБ