Это больше вопрос / проблема проектирования системы, чем вопрос кодирования.
По сути, я собираюсь собрать в Facebook Bejeweled -esque игру, используя только HTML, CSS и javascript. Это в основном из-за желания изучить все маленькие предостережения FBJS через нетривиальный проект.
Так вот в чем дело. При разработке для Facebook реальные вызовы API очень дороги; Мало того, что есть дополнительные POST для серверов Facebook, есть также предел вызовов API и регулирование, о которых нужно беспокоиться. Короче говоря, чем меньше звонков в Facebook, тем лучше. Объедините это с проблемами времени даже в этой простой игре-головоломке, и есть веская причина агрессивно минимизировать количество обратных вызовов в целом.
Не будучи экспертом по безопасности, вот дизайн, который я придумал:
- Вставить случайное семя в страницу игры.
- Используйте это семя для создания игрового поля (а также дополнительных фигур по мере необходимости).
- Изменяйте начальное число (xor, concateate и hash, что-то в этом роде) после каждого хода игрока, основываясь на времени с последнего хода. Редактировать: Я, вероятно, должен также включить фактический ход, предпринятый в мутировавшем семени.
- После завершения игры напишите следующее: время начала игры, каждый предпринятый ход и когда, и результаты на стороне клиента.
- На сервере перезапустите игру с указанными данными, проверьте работоспособность времени начала и хода, а затем подтвердите, что результаты совпадают.
- Чтобы уменьшить отказ в обслуживании, сама игра будет настроена так, чтобы иметь возможность выиграть к ходу X.
- Для предотвращения использования сервера в качестве «оракула» пользователь, отправляющий недействительную игру, будет забанен на некоторое постоянное время X (X порядка нескольких минут).
Для этого дизайна требуется три вызова Facebook на каждую сыгранную игру: один для сохранения случайного начального числа до начала игры, один для извлечения его после завершения игры и один для обновления счета игрока, если игра действительна.
Что я пытаюсь доказать, система против прямой спуфинг ( http: // ...? Myscore = 999999999 или аналогичный). Я также хотел бы смягчить атаки «забегая вперед», в которых пользователь может сказать, какие части поступают на доску в следующий раз. Атаки отказа в обслуживании на хост-сервере (преднамеренные или иные) также должны быть предотвращены.
Фактический вопрос, кто-нибудь может увидеть недостаток в этом дизайне? Эквивалентно, есть ли более простой дизайн, который соответствует моим критериям?
Примечание: я знаю, насколько это ненужно, но, тем не менее, это интересный вопрос.
<ч />
Я попытаюсь привести некоторые цифры здесь, чтобы проиллюстрировать мои рассуждения, они довольно грубые, но я надеюсь, что они будут полезны.
Если предположить игровое поле 10х10, то есть ~ 200 потенциальных ходов (смена двух смежных фигур), большинство из которых являются недействительными. Скажем, в среднем на 5 ходов приходится 5 ходов. Если мы ограничим действия игрока кадром от 50 до 30 000 миллисекунд, то получится 149 750 потенциальных новых хэшей при условии, что алгоритм «настройки» не сбрасывает биты; Я уверен, что, по крайней мере, существует 10 000 потенциальных новых хэшей, которые должны быть рассчитаны злоумышленником при условии использования криптографически безопасного хэша. Если вы добавите алгоритм минимума-максимума, дерево решений взорвется очень быстро. Бросьте на это истечение игрового сеанса, скажем, 30 минут, и я считаю, что атака, потому что эквивалентна по сложности написанию небольшой программы-бота, чтобы играть за вас, от которой невозможно обоснованно защититься.