следующая
В клиентской части есть форма для создания промокода. Я поставил ограничение на их максимальное количество — 5 штук.
Если клиент одновременно 10 раз отправит форму на сервер, с высокой вероятностью у него получится обойти лимит. И проверка Promocode::count() > 5 в обработчике формы уже не поможет, как я понимаю
Мне также нужно отдать клиенту созданную модель, чтобы она добавилась в конец списка
Могут ли помочь синхронные очереди Queue::sync() в решении этой проблемы?
Троттлинг.
Отключение кнопки до конца выполнения кода в бэке?
Что-то на фронте защищать — не вижу смысла)
А если параллельная вкладка или пользователь юный хацкер?)
Ну кнопку то блокировать надо, от фантомных нажатий. На игровых грызунах бывает левый клик за 2-3 программных заходит.
data-attach-loading поставлю)
Ну и в параллельной тоже 1 раз выполниться.
Как вариант кол. запросов пользователя можно же в сессию записать. И эту сессию прочитать перед записью в модель. Не уверен что подход верный, но возможно поможет
При параллельных запросах, сессия может не успеть синкнутся, что в ней изменение произошло
Возможно поэтому варианты, что ты скинул выше используют redis и memcashed)
Я что-то пропустил в обсуждении, вероятно, но на уровне запроса почему не решается проблема?
Троттлинг пробовал, не подходит
А тупо в миддлваре проверить количество существующих записей?
При одновременных запросах, вставки одной секундой происходят. И проблема та же. Может ошибиться.
Плюс троттлинг
Ни троттлинг, ни проверка количества записей не успевают сработать, если отправить одновременно 10-20 запросов на создание
А что если формы одноразовым кодом подписывать ?)
А код успеет измениться между первым и вторым запросом?)
Он уникальный. Как работает подпись csrf в spa. Перед отправкой формы, первым идет запрос на получение уникального токена, и только после его получения, идет отправка формы с этим токеном.
А если время последнего созданного промокода проверять и отклонять запрос, если он младше N секунд? А следом проверять кол-во записей.
Так там и проблема, что они одним временем при одновременных запросах создаются
Дело в том, что запись просто не успевает создаться, чтобы ее проверить во втором запросе)
Обсуждают сегодня