Комментарии 13
Для чего в этой схеме S3, который подключён к ноде, но к которому ни клиент, ни nginx доступ не имеет?
Дополню комментарий выше.
Запуск нескольких процессов в одном контейнере противоречит концепции докера. Докер сделан так, чтобы запускать один процесс (не считая дочерних процессов). Не совсем понятно почему в скобках на схеме указан Docker Container, но уверен что автор имел ввиду что-то иное.
Про авторизацию рискну предположить:
Мне нравится своей простотой передача в URL через Query-параметр. Ввиду того что TLS шифрует все кроме хоста и порта это относительно безопасно. У такого подхода есть ряд недостатков, наиболее существенный из которых в том, что query-параметры обычно логируются на промежуточных серверах как части запроса, и если риск попадания токена в логи недопустим, то с таким вариантом возникают сложности. Для решения данной проблемы существует схема, которая основывается на разделении сессионного токена и отдельного токена для установки WebSocket-соединения.
Так же есть вариант:
Сначала можно выполнить обычный HTTP-запрос авторизации (например, POST запрос для получения токена). После успешной аутентификации можно сохранять токен в локальном хранилище (localStorage) или куках и затем устанавливать WebSocket-соединение.
Проект интересен с точки зрения "подводных камней" и фич, которые могут быть полезны для разработчиков.
Жду следующих частей!
Вы совершенно правы относительно концепции докера и он указан в скобках скорее как один из вариантов развертывания приложения. В статье я упоминал о масштабировании за счет увеличения количества cpu/vcpu и в схеме хотел отразить именно этот подход.
Про авторизацию также соглашусь с вами, вариант с передачей токена в url я использовал в первой версии игры и действительно его единственный минус на мой взгляд это попадание токена в логи. Сейчас я использую куку с коротким сроком действия которую вешаю перед подключением и удаляю сразу после этого. Интересно было бы узнать ваше мнение на этот счет, с учетом того, что хранить локально токены доступа я категорически не хочу ни в localStorage ни где либо еще.
Спасибо за интерес к проекту!
Вы в первой части написали, что не использовали веб фреймворки, а обошлись typescript + html+ css, вот об этом подробности было бы интересно почитать.
Интересная реализация. Вот только 4 кубика показывать не обязательно, лучше пусть будет 2 как в нормальной игре. И вопрос про рандом цифр, чтобы-то четверка прямо одна за одной шла, может конечно совпадение, но во всех 10 бросках она выпадала.
4 кубика я решил использовать в случае дубля для наглядности количества сделанных ходов. После каждого хода соответствующий кубик становится полупрозрачным.
Вопросы к рандомайзеру кстати становятся уже обычным делом, по этому небольшой спойлер из следующей части.
В процессе старта игры, на сервере генерируется случайная комбинация первого броска, который нужен для определения того, кто играет белыми и делает первый ход, а также 128 бросков кубиков, которые можно скачать в виде архива с паролем в любой момент игры. Пароль будет выдан после завершения игры. Таким образом гарантируется неизменность всех предварительно сгенерированных бросков и подтверждается честность игры.
Сейчас для генерации используется классический Math.floor(Math.random() * 6) + 1, я посчитал, что его будет достаточно, а вы как думаете?
Интересный подход с комбинацией. 128 бросков будет достаточно как думаете, если скажем даже всегда будет выпадать 1 + 2 или в случаи блокировки соперника.
Как я создавал онлайн игру «нарды» (часть вторая). Сервер