Здравствуйте, уважаемые!

При создании скриптов для взаимодействия с платежными системами возник следующий вопрос.

Есть ли смысл защищать БД от засорения? Ведь капча или же подтверждение электронного адреса перед оплатой займет лишнее время.

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

Какие есть решения данной проблемы, учитывая то что новые записи, добавленные INSERT, у меня должны сохраняться в течении суток?

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

Есть ли смысл в таком подходе? Может быть лучше использовать CRON?

Тут явно что-то не то.

А если IP совершенно разные?
Тогда получается, что надо всю цепочку отправлять в баню!

Допустим, банить на какое-то время. И времени на совершение операции давать по-минимуму. Только вот какие значения будут оптимальны?

Учитывая возможности mysql, cron'ом тут не ограничиться.
Надо свести риск к минимуму.
Допустим, кроме пхп, больше ничего и не предусмотрено.

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

Наверное, придется импровизировать!

Так а как вообще эта защита работает?
Точно то никак не определишь кто есть кто!

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

Так может просто сделать каптчу для всех кто оказался в цепочке??

a1ex

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

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Спасибо за ответы!
Насчет ddos понятно, что php не обойтись!
По идее, от засорения БД такие меры помогут!

Если у заказа есть id, ну или номер заказа, то на этот номер заказа поставить PRIMARY KEY и тогда нельзя будет добавлять по сто раз одно и тоже.

_____________
Gear Framework
Gear Framework на Github

linker
Это только процесс создания заказа.