потому что session_id должен быть привязан к id пользователя, это как бы основы. По session_id сервер восстанавливает user_id. Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.
а в jwt обычно прописывают user_id, поменять ты его не сможешь, токен будет невалидныйДа, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачу и получаю результат, как если бы я использовать jwt. В моем случае - все данные находятся в зашифрованном виде, и расшифровывать их может только бэк. В случае невозможности расшифровки - запрос отбрасывается на страницу авторизации. В случае даже гипотетического перехвата этого ключа, при попытке открыть /app - перекидывает на /one, т.к. в зашифрованном виде есть некий reload, который не позволит второй раз открыть страницу.
Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.
Достаточно сразу коннетиться к вебсокет, а на сервере разрешить только один коннект от телеграм id
как это вообще связанно с для масштабируемостью?
А зачем эти one, two, бессмысленное шифрование, какой-то непонятный набор действий
А зачем мне хранить 2 сессии одного пользователя, когда задача стоит не допускать 2 одновременных сессии одного пользователя.
Потому что для отрисовки страницы приложения я использую данные из websocket. Большинство данных получаются из ws. я не говорю про html/css/js, я говорю про данные условно - псевдоним, баланс, текущий счет, достижения.
Не использую. Использую своё решение, в котором хочу понять слабые места.