Adamos, ну так это и есть всё в одном скрипте. Возникающие ошибки - можно скидывать в файлик, чтобы не искать. А если что - дебаг по-любому придётся включать.
Adamos, ну если у кого доступ пропадёт пусть пишут в ТП. А вообще, да: нужен идентификатор устройства блочить. В данном случае так: UDID = IP+[доп.данные клиента].
Если клиент никак не представился - тогда вполне можно "ломать дрова"! ;)
Adamos, Согласен!
Ну, можно по-старинке: 2 подряд некорректных запроса к хосту => IP в перманентный бан с алертом на почту. И тупо, и просто, и (не 100%, но максимально!) надёжно! :)
Adamos, неа. как раз лучше доп. полями (уникализировать "тело" запроса).
Т.к. ключ - меняется раз в X-запросов или раз в течение заданного промежутка времени (или, иногда встречается в половине случаев, по требованию клиента: init-session).
А каждое обращение к API - это ОДИН запрос и он уникальный!
Простое правило: перед обработкой запроса - целиком запрос к API (не хешированный) сохраняем в таблицу как отработанный на максимальное время жизни токена!
Ключевое поле - сам этот запрос: INSERT с ошибкой - никакого исполнения запроса!
И, конечно, плюс к этому, периодическая смена ключа - нужна обязательно!
Adamos, ну там где-то я отвечал на тостере...
Сайты типа: "Ловим инопланетян телескопом! Подключай свой комп - помоги нам в обработке данных в то время, пока вас нет за компом и работает скрин-сэвер или когда CPU простаивает. Ставь софт - участвуй в проекте планетарного масштаба!" (А мы пока пакеты с хешами подготовим для поиска ключей))))
Adamos, не только: это помогает от выявления алгоритма хеширования, если MiTM'у удалось перехватить много запросов одного юзера с одними и теми же параметрами к API и одним токеном. Т.е., до сервера - здесь пока сам запрос и не дошёл и, соответственно, он не может предотвратить ничего, т.к. попросту не участвует в цепочке.
хостер (Таймвеб) своими роботами регулярно щупает мои скрипты, к которым происходят внешние обращения
Можно по хидерам фильтровать таких роботов средствами веб-сервера (правилами): есть нужный - пропускать, нет - блочить, чтобы даже до скрипта это не доходило.
Stalker_RED, ну можно меткость лимитировать: ставить как у тебя или 80% от твоей. Тоже касается и скорости переходов от юнита к юниту в RTS - APM (actions per minute).
Т.е. реакцию - ставить по-процентно от твоей средней. А остальное - уже "реалтайм шахматы".
explorador, потому, что бот-"младенец" (который ничего не знает), сможет обучаться вашей тактике по мере игры. И потом, Вы увидите зеркальное нападение и будете применять уже другую тактику, а бот - будет продолжать учиться.
Если кооператив - ещё интереснее. 2x2 - 2 человека и 2 бота.
Притом, могут быть как с одной стороны все боты, так и человек+бот против человека+бота.
Т.е., появятся виртуальные игроки вместе с реальными, которых реальные смогут готовить под свою стратегию игры и по-своему использовать различные комбинации войск при удержании территории, защите или нападении.
Это новый уровень игр для игроков: вырастить одного (или взвод ботов) у себя на компе, постоянно играя с ними и тренируя их на разные ситуации, против разных соперников и т.д.
