PHP - это хороший метод для предотвращения повторной отправки?

Question

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

Поскольку удаление элементов происходит часто, использование БД для хранения уникального «идентификатора удаления транзакции» кажется мне неосуществимым. Я развлекаю идею ниже:

1. Для каждого боя создается уникальное значение на основе текущей даты-времени, идентификатора пользователя и сохраняется его в БД и сеансе. Возможно, что при наличии идентификатора пользователя вы можете получить значение обратно

2. Если значение из сеанса существует в БД, то «бой» действителен и позволяет пользователю получить доступ ко всем страницам, относящимся к бою. Если он не существует в БД, то запускается новое боевое состояние

3. По окончании боя уникальное значение удаляется из БД.

4. Значения, которым в БД 30 минут, удаляются.

Любые мнения, улучшения или недостатки этого метода приветствуются

Answer 1

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

Решение, которое вы предоставили, должно работать, но оно зависит от имеющихся у вас уникальных боевых / лут / пользовательских данных.

Я так понимаю, это то, что вы считаете лучшим? Это то, что я считаю лучшим:)

1. Получите ID пользователя вместе с уникальным фрагментом данных этого боя. Что-то вроде времени начала боя, времени окончания боя и т. Д.
2. Храните его в базе данных или в какой-либо другой системе хранения, которую вы используете
3. Как только вы соберете добычу, удалите эту запись

Таким образом, если этот ИД пользователя и эти уникальные боевые данные существуют, у них нет добычи.

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

Answer 2

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

Окончание боя и выпадение добычи должны рассматриваться как обычная операция. Если нет драки, не может быть никакого выпадающего лута.

Answer 3

Это зависит от вашего игрового дизайна: вы идете больше в направлении roguelikes, где учитывается только количество ходов, и, следовательно, длинные паузы между ходами определенно возможны (например, консультирование других людей через чат, обратите внимание: в NetHack это не рассматривается мошенничество)? Могут ли пользователи сохранять свои игры только в определенных точках или в любом месте? Это имеет огромное значение в дизайне, например, прокладывая путь для подвигов, подобных тому, о котором упоминал Торарин.

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

Answer 4

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