Не позволяя сценаристам захлопнуть ваш сайт

Question

Я принял ответ, но, к сожалению, я думаю, что мы застряли в нашем исходном сценарии наихудшего случая: CAPTCHA каждый на попытки покупки дерьма . Краткое объяснение: кэширование / веб-фермы делают невозможным отслеживание хитов, и любой обходной путь (отправка не кэшированного веб-маяка, запись в объединенную таблицу и т. Д.) Замедляет работу сайта хуже, чем это делают боты. Вероятно, есть какое-то дорогостоящее аппаратное обеспечение от Cisco или подобное, которое может помочь на высоком уровне, но трудно оправдать стоимость, если CAPTCHA для всех является альтернативой. Позже я попытаюсь дать более полное объяснение, а также очистить его для будущих поисковиков (хотя другие могут попробовать, поскольку это вики сообщества).

Положение

Речь идет о распродажах на сайте woot.com. Я президент Woot Workshop, дочерней компании Woot, которая занимается дизайном, пишет описания продуктов, подкасты, сообщения в блогах и модерирует форумы. Я работаю с CSS / HTML и едва знаком с другими технологиями. Я тесно сотрудничаю с разработчиками и обсудил все ответы здесь (и многие другие идеи, которые у нас были).

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

Боты отбрасывают нашу главную страницу десятки раз за секунду, просматривая экран (и / или сканируя наш RSS) для продажи Случайного Дерьма. В тот момент, когда они видят это, он запускает второй этап программы, которая входит в систему, нажимает кнопку «Мне нужен один», заполняет форму и покупает дерьмо.

Оценка

lc : На stackoverflow и других сайтах, использующих этот метод, они почти всегда имеют дело с аутентифицированными (вошедшими в систему) пользователями, поскольку для выполняемой задачи требуется это.

На Woot анонимные (не зарегистрированные) пользователи могут просматривать нашу домашнюю страницу. Другими словами, захлопывающие боты могут быть не аутентифицированы (и, по сути, не отслеживаются, кроме как по IP-адресу).

Итак, мы вернулись к сканированию IP-адресов, которые а) довольно бесполезны в наш век облачных сетей и спамботов-зомби и б) ловят слишком много невинных, учитывая количество предприятий, которые приходят с одного IP-адреса (не говоря уже о проблемы с нестатическими IP-провайдерами и потенциальные потери производительности при попытке отследить это).

О, и если бы люди звонили нам, это был бы наихудший сценарий. Можем ли мы заставить их позвонить вам?

BradC : методы Неда Батчелдера выглядят довольно круто, но они достаточно твердо разработаны, чтобы победить ботов, созданных для сети сайтов. Наша проблема в том, что боты созданы специально для победы над нашим сайтом. Некоторые из этих методов могут работать недолго, пока сценаристы не разовьют своих ботов, чтобы игнорировать honeypot, просматривать экранные имена соседних меток вместо идентификаторов форм и использовать элемент управления браузером с поддержкой javascript.

lc again : «Если, конечно, реклама не является частью вашей маркетинговой схемы». Да, это определенно так. Удивление того, когда предмет появляется, а также волнение, если вам удастся его получить, вероятно, столь же или более важно, чем дерьмо, которое вы фактически получаете в итоге. Все, что исключает «первым пришел / первым обслужен», отрицательно сказывается на «выигрыше» дерьма.

novatrust : И я, например, приветствую наших новых повелителей ботов. На самом деле мы предлагаем RSS-каналы, позволяющие сторонним приложениям сканировать наш сайт на предмет информации о продукте, но не опережая основной сайт HTML. Если я правильно понимаю, ваше решение помогает цели 2 (проблемы с производительностью), полностью жертвуя целью 1 и просто отказываясь от того факта, что боты будут покупать большую часть дерьма. Я проголосовал за ваш ответ, потому что ваш последний пессимизм кажется мне точным. Кажется, здесь нет серебряной пули.

Остальные ответы, как правило, основаны на отслеживании IP-адресов, которые, опять-таки, кажутся бесполезными (с ботнетами / зомби / облачными сетями) и вредными (ловят многих невинных, которые прибывают из пунктов назначения с одинаковым IP).

Есть ли другие подходы / идеи? Мои разработчики продолжают говорить «давайте просто сделаем CAPTCHA», но я надеюсь, что есть все менее навязчивые методы для всех реальных людей, желающих получить немного нашего дерьма.

Оригинальный вопрос

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

В итоге вы получаете сценаристов и ботов, пытающихся программно [а] выяснить, когда вы продаете указанный товар, и [б] убедитесь, что они одними из первых купили его. Это отстой по двум причинам:

1. Ваш сайт захвачен не людьми, замедляя все для всех.
2. Сценаристы в итоге «выигрывают» продукт, заставляя завсегдатаев чувствовать себя обманутыми.

На первый взгляд очевидное решение - создать несколько пялец, через которые ваши пользователи будут проходить, прежде чем размещать свой заказ, но с этим есть как минимум три проблемы:

• Пользовательский опыт - отстой для людей, поскольку они должны расшифровать CAPTCHA, выбрать кота или решить математическую задачу.
• Если воспринимаемая выгода достаточно высока, а толпа достаточно велика, какая-то группа найдет способ обойти любую хитрость, ведущую к гонке вооружений. (Это особенно верно, чем проще твик: скрытая форма «комментарии», переупорядочивание элементов формы, неправильная маркировка, скрытый текст «поймал» - все будет работать один раз, а затем его нужно будет изменить для борьбы с этой конкретной формой .)
• Даже если сценаристы не могут «решить» ваш твик, это не помешает им хлопнуть вашей первой страницей, а затем подать сигнал тревоги для сценария, чтобы он выполнил заказ вручную. Учитывая, что они получают преимущество от решения [a], они, вероятно, все равно выиграют [b], так как они будут первыми, кто достигнет страницы заказа. Кроме того, 1. все еще происходит, вызывая ошибки сервера и снижение производительности для всех.

Другое решение состоит в том, чтобы следить за слишком частым попаданием IP-адресов, блокировать их от брандмауэра или иным образом предотвращать их упорядочение. Это может решить 2. и предотвратить [b], но снижение производительности при сканировании IP-адресов является значительным и, вероятно, вызовет больше проблем, таких как 1., чем сами сценаристы. Кроме того, возможность облачных сетей и спамботных зомби делает проверку IP довольно бесполезной.

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

Цель

1. Продайте предмет людям, не пишущим сценарий.
2. Поддерживайте работу сайта на скорости, не замедляемой ботами.
3. Не доставляйте «обычным» пользователям никаких заданий, чтобы доказать, что они люди.

Answer 1

Отказ от ответственности: Этот ответ совершенно не связан с программированием. Однако, в первую очередь, он пытается атаковать причину сценариев.

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

Есть много других вариантов, и я уверен, что другие могут подумать о некоторых других:

• очередь заказов (система предварительного заказа) - некоторые сценарии могут по-прежнему находиться в начале очереди, но, вероятно, быстрее просто ввести информацию вручную.

• система лотереи (каждый, кто пытается ее заказать, входит в систему) - таким образом, у людей со сценариями есть те же самые шансы, что и у тех, у кого нет.

• очередь срочного приоритета - Если действительно высокая воспринимаемая ценность, люди могут быть готовы платить больше. Реализуйте очередь заказов, но разрешите людям платить больше, чтобы их помещали в очередь выше.

• аукцион (в этом заслуга Дэвида Шмитта, комментарии принадлежат мне). Люди могут по-прежнему использовать сценарии, чтобы подстрелить в последнюю минуту, но это не только меняет структуру ценообразования, люди ожидают бороться с другими. Вы также можете сделать что-то, чтобы ограничить количество ставок за определенный период времени, заставить людей заранее позвонить для получения кода авторизации и т. Д.

Answer 2

Я говорю, выставить информацию о ценах с помощью API. Это не интуитивное решение, но оно работает, чтобы дать вам контроль над ситуацией. Добавьте некоторые ограничения в API, чтобы сделать его немного менее функциональным, чем веб-сайт.

Вы можете сделать то же самое для заказа. Вы можете экспериментировать с небольшими изменениями в функциональности / производительности API, пока не получите желаемый эффект.

Есть прокси и ботнеты, чтобы победить проверки IP. Есть сценарии чтения капчи, которые очень хороши. В Индии даже есть группы рабочих, которые за небольшую цену побеждают капчи. Любое решение, которое вы можете найти, может быть разумно побеждено. Даже решения Неда Батчелдера можно обойти, используя элемент управления WebBrowser или другой имитированный браузер в сочетании со списком ботнетов или прокси.

Answer 3

В настоящее время для этого мы используем балансировщики нагрузки BigIP последнего поколения от F5. BigIP имеет расширенные функции управления трафиком, которые могут идентифицировать скребки и ботов на основе частоты и моделей использования даже из множества источников за одним IP. Затем он может регулировать их, предоставлять им альтернативный контент или просто помечать их заголовками или файлами cookie, чтобы вы могли идентифицировать их в коде своего приложения.

Answer 4

Как насчет введения задержки, которая требует взаимодействия с человеком, как своего рода «игра CAPTCHA». Например, это может быть небольшая флэш-игра, в которой в течение 30 секунд они должны взрывать клетчатые шары и избегать взрывов сплошных шаров (избегая проблем с дальтонизмом!). В игре будет задано начальное число случайных чисел, и то, что игра передаст обратно на сервер, будет координатами и отметками времени нажатых точек вместе с используемым начальным числом.

На сервере вы моделируете игровую механику, используя это начальное число, чтобы увидеть, действительно ли щелчки лопнули шары. Если они это сделали, они были не только людьми, но и потратили 30 секунд, чтобы утвердить себя. Дайте им идентификатор сессии.

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

Answer 5

Во-первых, позвольте мне напомнить, что нам нужно сделать здесь. Я понимаю, что я просто перефразирую исходный вопрос, но важно, чтобы мы получили это 100% прямо, потому что есть много отличных предложений, которые дают 2 или 3 из 4 правильных, но, как я покажу, вам понадобится многогранный подход для удовлетворения всех требований.

Требование 1: избавиться от «хлопанья ботом»:

Стремительный «грохот» вашей первой страницы ухудшает производительность вашего сайта и лежит в основе проблемы. «Хлопание» происходит как от ботов с одним IP, так и, предположительно, от ботнетов. Мы хотим избавиться от обоих.

Требование 2: Не связывайтесь с опытом пользователя:

Мы могли бы довольно эффективно исправить ситуацию с ботом, внедрив неприятную процедуру проверки, например, позвонив человеку-оператору, решив кучу CAPTCHA или подобное, но это было бы как заставить любого невинного пассажира самолета прыгать через сумасшедшие обручи безопасности только для малый шанс поймать самых глупых террористов. Ой, подождите - мы на самом деле делаем это. Но давайте посмотрим, сможем ли мы , а не сделать это на woot.com.

Требование 3: Избежать «гонки вооружений»:

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

Требование 4: Срыв ботов «тревоги»:

Это может быть самым сложным из ваших требований. Даже если мы сможем выполнить эффективную задачу проверки личности, боты все равно смогут опросить вашу главную страницу и предупредить сценариста о появлении нового предложения. Мы хотим, чтобы эти боты также были неосуществимыми. Это более сильная версия первого требования, поскольку боты не только не могут выдавать быстродействующие запросы, снижающие производительность, но и не могут выдавать достаточно повторных запросов, чтобы вовремя отправить «тревогу» в сценарий, чтобы выиграть предложение.

---

Хорошо, давайте посмотрим, сможем ли мы удовлетворить все четыре требования. Во-первых, как я уже говорил, ни одна мера не поможет. Вам нужно будет объединить пару трюков, чтобы достичь этого, и вам придется проглотить две неприятности:

1. Небольшое количество пользователей будет необходимо прыгать через обручи
2. Небольшое количество пользователей не сможет получить специальные предложения

Я понимаю, что это раздражает, но если мы сможем сделать "маленькое" число достаточно маленьким , я надеюсь, что вы согласитесь, что положительные перевешивают отрицательные.

Первая мера: регулирование на уровне пользователя:

Это не просто, и я уверен, что вы уже это делаете. Если пользователь вошел в систему и продолжает обновлять 600 раз в секунду (или что-то в этом роде), вы перестаете отвечать и говорите ему, чтобы он остыл. На самом деле, вы, вероятно, дросселируете его запросы значительно раньше, но вы поняли идею. Таким образом, авторизованный бот будет заблокирован / заблокирован, как только он начнет опрашивать ваш сайт. Это легкая часть. Боты, не прошедшие проверку подлинности, - это наша настоящая проблема:

Вторая мера: некоторая форма регулирования IP, как предлагают почти все:

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

Падение производительности незначительно, если вы запускаете проверку IP перед любой другой обработкой, используете прокси-сервер для логики регулирования и сохраняете IP-адреса в древовидной структуре, оптимизированной для поиска по memcached.

Третья мера: закрытие дросселя кэшированными ответами:

При быстром включении ботов с одним IP-адресом нам все еще приходится обращаться к медленным ботам с одним IP, т.е. боты, специально настроенные так, чтобы «летать под радаром», размещая запросы немного дальше друг от друга, чем предотвращает регулирование.

Чтобы мгновенно сделать медленных ботов с одним IP бесполезными, просто используйте стратегию, предложенную abelenky: обслуживайте 10-минутные кэшированные страницы всем IP-адресам, которые были обнаружены за последние 24 часа (или около того). Таким образом, каждый IP получает один «шанс» в день / час / неделю (в зависимости от выбранного периода), и не будет видимого раздражения для реальных пользователей, которые просто нажимают «перезагрузить», за исключением того, что они не выигрывают предложение.

Прелесть этой меры в том, что также мешает «тревожным ботам», если они не происходят из ботнета.

(я знаю, что вы, вероятно, предпочли бы, чтобы реальным пользователям разрешалось обновляться снова и снова, но нет способа отличить человека, обновляющего спам, от бота, рассылающего запросы, без CAPTCHA или подобного)

Четвертая мера: reCAPTCHA:

Вы правы в том, что капчи наносят вред пользовательскому опыту и его следует избегать. Однако в ситуации _one_ они могут быть вашим лучшим другом: если вы разработали очень строгую систему для предотвращения ботов, то - из-за ее ограниченности - также обнаруживается ряд ложных срабатываний; затем CAPTCHA служил в качестве крайней меры , что позволит тем реальным пользователям, которые попали в ловушку при вашем регулировании (таким образом, избегать раздражающих ситуаций DoS).

Самое приятное, конечно, это то, что ВСЕ боты попадают в вашу сеть, в то время как CAPTCHA беспокоит крайне мало реальных пользователей.

Если вы при обслуживании 10-минутных кэшированных страниц также предлагаете альтернативный необязательный проверенный CAPTCHA «переполнитель главной страницы», тогда люди, которые действительно хотите продолжать обновлять, все еще можете сделать это без получения старой кэшированной страницы, но за счет необходимости решать CAPTCHA для каждого обновления. То, что - это раздражение, , но необязательное только для преданных пользователей, которые склонны быть более снисходительными, потому что они знают , что они разыгрывают систему улучшить свои шансы, и эти улучшенные шансы не приходят бесплатно.

Пятая мера: Дерьмо-приманка:

У Кристофера Махана была идея, которая мне скорее понравилась, но я бы придал ей другое значение. Каждый раз, когда вы готовите новое предложение, готовьте также два других «предложения», которые ни один человек не выберет, например, 12-мм грецкий орех за 20 долларов. Когда предложение появится на первой странице, поместите все три «предложения» на одном изображении с номерами, соответствующими каждому предложению. Когда пользователь / бот на самом деле переходит к заказу предмета, ему нужно будет выбрать (радио-кнопку) то предложение, которое они хотят, и, поскольку большинство ботов просто догадываются, в двух из трех случаев боты будут покупать ничего не стоящие старья.

Естественно, это не относится к «ботам-будильникам», и есть (тонкий) шанс, что кто-то сможет построить бота, который сможет выбрать правильный предмет. Однако риск случайной покупки мусора должен заставить сценаристов полностью отказаться от полностью автоматизированных ботов.

Шестая мера: регулирование ботнета:

[удалено]

Хорошо ............ Теперь я провел большую часть вечера, размышляя об этом, пробуя разные подходы ... глобальные задержки ... маркеры на основе файлов cookie ... обслуживание в очереди ... "незнакомец душит" .... И это просто не работает. Это не так. Я понял, что основная причина, по которой вы еще не приняли никакого ответа, заключается в том, что никто не предложил способ предотвратить атаку распределенной / зомби-сети / ботнета .... поэтому я действительно хотел взломать его. Мне кажется, я решил проблему с ботнетом для аутентификации в другом потоке , поэтому я также возлагал большие надежды на вашу проблему. Но мой подход не относится к этому. У вас есть только IP-адреса, и достаточно большой ботнет не обнаруживает себя ни в одном анализе, основанном на IP-адресах.

Итак, вот оно у вас : Моя шестая мера - ничто. Ничего такого. Zip. Если ботнет не является маленьким и / или достаточно быстрым, чтобы попасть в обычный IP-дроссель, я не вижу каких-либо эффективных мер против бот-сетей, которые не требуют явной проверки человеком такие как CAPTHA. Извините, но я думаю, что сочетание пяти вышеперечисленных мер - ваш лучший выбор. И вы, вероятно, могли бы справиться с этим только с помощью 10-минутного кеширования Абеленки.

Answer 6

Напишите обратный прокси на сервере apache перед вашим приложением, которое реализует Tarpit (статья в Википедии) для наказания ботов. Он будет просто управлять списком IP-адресов, которые подключены за последние несколько секунд. Вы обнаруживаете пакет запросов с одного IP-адреса, а затем экспоненциально задерживаете эти запросы, прежде чем ответить.

Конечно, несколько человек могут приходить с одного и того же IP-адреса, если они подключены к сети через NAT, но маловероятно, что человек будет против того, чтобы ваше время ответа составляло от 2 до 4 мс (или даже 400 мс), тогда как бот будет увеличиваться задержка довольно быстро.

Answer 7

Уже опубликовано несколько других / лучших решений, но для полноты я решил упомянуть следующее:

Если ваша основная проблема - снижение производительности, и вы смотрите на истинное удар , то вы на самом деле имеете дело с атакой DoS, и вам, вероятно, следует попытаться справиться с ней соответствующим образом. Один из распространенных подходов - просто отбрасывать пакеты с IP в брандмауэре после количества соединений в секунду / минуту / и т. Д. Например, стандартный брандмауэр Linux iptables имеет стандартную функцию сопоставления операций 'hashlimit', которую можно использовать для сопоставления запросов на соединение за единицу времени с IP-адресом.

Хотя этот вопрос, вероятно, был бы более уместным для следующего SO-производного, упомянутого в последнем SO-подкасте, он еще не запущен, поэтому я думаю, что это нормально, чтобы ответить:)

EDIT:
Как отмечает novatrust, все еще существуют интернет-провайдеры, которые фактически НЕ назначают IP-адреса своим клиентам, поэтому клиент-скрипт такого провайдера эффективно отключает всех клиентов от этого провайдера.

Answer 8

Придерживайтесь 5-минутной задержки во всех анонсах продукта для незарегистрированных пользователей. Обычные пользователи на самом деле этого не заметят, и не зарегистрированные пользователи все равно будут зарегистрированы.

Answer 9

1. Предоставьте канал RSS, чтобы они не съешь свою пропускную способность.
2. При покупке, заставить всех ждать случайных количество времени до 45 секунд или что-то, в зависимости от того, что вы ищете именно. Именно так каковы ваши временные ограничения?
3. Дайте всем 1 минуту, чтобы ввести свое имя для рисунка, а затем случайным образом выбирать людей. Я думаю, что это самый справедливый путь.
4. Контролируйте учетные записи (включаете ли вы несколько раз в сеанс и сохраняете ли они?) И добавляйте задержки к учетным записям, которые кажутся ниже порога человеческой скорости. Это, по крайней мере, заставит ботов запрограммироваться на замедление и соревнование с людьми.

Answer 10

Прежде всего, по определению, невозможно поддерживать транзакции без сохранения состояния, то есть по-настоящему анонимные транзакции, и при этом иметь возможность отделять ботов от легитимных пользователей.

Если мы сможем принять предпосылку, что мы можем наложить определенную цену на совершенно нового шутника-посетителя на его первых страницах, я думаю, у меня есть возможное решение. Из-за отсутствия лучшего названия я собираюсь назвать это решение «Визит в DMV».

Допустим, есть автосалон, который предлагает новый автомобиль каждый день, и что в некоторые дни вы можете купить экзотический спортивный автомобиль за 5 долларов США (лимит 3) плюс 5 долларов США за доставку в пункт назначения.

Суть в том, что дилерский центр требует, чтобы вы посетили дилерский центр и предъявили действительные водительские права, прежде чем вас пропустят через дверь, чтобы посмотреть, какой автомобиль продается. Кроме того, для совершения покупки вы должны были указать действительные водительские права.

Итак, посетителю, впервые приехавшему (пусть назовем его Бобом) к этому автомобильному дилеру, будет отказано во въезде, и его направят в офис DMV (который удобно расположен по соседству) для получения водительских прав.

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

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

Водительские права в этом мире почти невозможно подделать.

Посещение DMV предполагает сначала получение формы заявки в очереди «Начни здесь». Боб должен перенести заполненное заявление в окно № 1, где первый из многих унылых государственных служащих возьмет его заявление, обработает его и, если все в порядке, поставит печать на окне и отправит его в следующее окно. И вот, Боб переходит из окна в окно, ожидая, когда пройдёт каждый шаг его приложения, пока он, наконец, не доберется до конца и не получит лицензию своего привода.

Нет смысла пытаться «замкнуть накоротко» DMV. Если формы заполнены неправильно в трех экземплярах или если в каком-либо окне даны неправильные ответы, приложение разрывается и несчастный клиент отправляется обратно на старт.

Интересно, что независимо от того, насколько полным или пустым является офис, требуется примерно одинаковое количество времени для обслуживания в каждом последующем окне. Даже когда вы единственный человек в очереди, персоналу нравится заставлять вас подождать минуту за желтой линией, прежде чем произнести «Далее!»

Однако в DMV все не так ужасно. Пока идет ожидание и обработка, чтобы получить лицензию, вы можете посмотреть очень интересный и информативный рекламный ролик для автосалона, пока вы находитесь в вестибюле DMV. Фактически, информационный ролик работает достаточно долго, чтобы покрыть количество времени, которое вы тратите на получение лицензии.

Чуть более техническое объяснение:

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

Этот подход, вероятно, требует AJAX-y обработки на стороне клиента. Абсолютно новый посетитель в woot получает "Добро пожаловать новый пользователь!" страница, заполненная текстом и графикой, которая (при соответствующем регулировании на стороне сервера) занимает несколько секунд для полной загрузки. Пока это происходит (и посетитель, по-видимому, занят чтением страниц приветствия), его идентификационный токен медленно собирается.

Допустим, для обсуждения токен (он же «водительское удостоверение») состоит из 20 блоков. Чтобы получить каждый последующий фрагмент, код на стороне клиента должен отправить на сервер действительный запрос. Сервер имеет намеренную задержку (скажем, 200 миллисекунд), перед отправкой следующего фрагмента вместе с «штампом», необходимым для выполнения следующего запроса фрагмента (т. е. штампы, необходимые для перехода из одного окна DMV в другое). В общем, должно пройти около 4 секунд завершить процесс чанка-вызов-ответ-чанк-вызов-ответ -...- чанк-вызов-ответ-завершение.

В конце этого процесса у посетителя появляется токен, который позволяет ему перейти на страницу описания продукта и, в свою очередь, перейти на страницу покупки. Маркер является уникальным идентификатором каждого посетителя и может использоваться для ограничения его активности.

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

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

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