вопрос с правообладателями решается с помощью оферты (консультировался по этому вопросу с юристами)ахаха, если бы всё так просто, виноват в распространении будешь именно ты, никакая оферта тебя тут не спасет. А еще CP и да политика ща тоже может оказаться очень токсичной, а придут-то в первую очередь именно к тебе, и не факт, что офертой ты сможешь прикрыться.
Как используя ТОЛЬКО user_id мы будем защищены от перебора этого самого user_id ?еще раз, почему вдруг ты сделал возможный что перебор user id дает подключится этому user id? только user_id и какие-то данные его идентифицирующие, только так.
Аналогично в http - сделать страницу в которой нужно ввести только свой логин (без пароля), далее у нас запишется кукиса по которой сайт будет считать меня username , и я буду прекрасно видеть все данные, который username оставил на странице.зачем так делать?
Потому что для отрисовки страницы приложения я использую данные из websocket.И что это меняет? Чтобы создать коннект к веб сокету, ты используешь сессию связанную с юзером, всё дальше твой сервер знает что этот коннект от этого юзера, не нужно гонять его id. Мне кажется у тебя вообще нет понимания как работают вебсокеты.
Использую своё решениетебе равно использовать "свои решения", ты не понимаешь как общепринятые работают. Используй готовые стандартные реализации, тогда у тебя не будет проблем.
Старая сессия на бэке удаляетсязачем? но если удалил, то заново создай ее, у тебя есть initdata, то точно можешь подтвердить юзера, перебор user id тут не поможет
перебираю user_id.почему вдруг перебор user_id должен на что-то влиять, почему вдруг знание user_id позволит подключиться под этим юзером?
Да, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачуне нужно упрощать jwt, нужно либо его использовать, либо нет.
в котором передается session_id соединения, id пользователя . Что помешает поменять id пользователя на свой,потому что session_id должен быть привязан к id пользователя, это как бы основы. По session_id сервер восстанавливает user_id. Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.
но вместо jwt использовал собственную реализацию access token.а в jwt обычно прописывают user_id, поменять ты его не сможешь, токен будет невалидный
Если самому генерить GUID, то какой шанс, что такой GUID уже будет?так же как и не самому, надеюсь ты про готовую реализацию говоришь, а не сам решил её реализовывать.
достаточно не сложно будет заняться перебором аккаунтов по IDстандартного механизма авторизации будет достаточно, а всё остальное это оверинженеринг