которые не сидят на шее у родителей, тоже предложишь за еду работать?по твоей логике, я должен спросить у кандидата, сидит ли он на шее у родителя или нет, и от этого что-то менять в предложении? Далее, "за еду работать" очень сильно субъективное, кому-то за еду, а кому-то и норм. Далее, джунов дофига, они в этом виде мало кому нужны, а те кому они нужны делают "отбор" и критерии этого отбора могут сильно меняться, в итоге получаем, что кому-то может сразу "повести", а кому-то этот "повести" вообще никак не упирается.
В таком случае я не знаю, как рекрутеры после выполненного ТЗ мне говорят "мы решили сделать выбор в пользу другого кандидата" такое количество раз.о, это отдельная тема с "бигтехами", срезать у них могут как сами HR, там и например, служба безопасности, хотя ты мог все ок пройти на собесах с разрабами.
Стек был типичного django разраба.да полная жопа с новичками на "django разраба", с базовыми знаниями всё плохо, дебажить мало кто способен, проблема n+1 опять без понимание, не сталкивались, как все таки в проде со static работать, опять затык, почему http запрос внутри синхронных view всё блочит, опять без ответа, создать в ORM чуть более сложную цепочку c annotate или aggregate - сложно, понимание транзакции и блокировок в бд - сложно и т.д. и т.п.
но смело везде кричите, какие они глупые и ничего не умеющие.где это я кричал? самостоятельно принимать решение это про другое качество, а не про эти
требования к разработке были "умею делать консольный калькулятор".а это требование даже сейчас актуально, и если в этой задачи нет уточнения, я вот например, минимум хочу услышать в ответ "мне сделать вот эти базовые операции, далее их перечисление или нужно добавить еще какие-то?"
вопрос с правообладателями решается с помощью оферты (консультировался по этому вопросу с юристами)ахаха, если бы всё так просто, виноват в распространении будешь именно ты, никакая оферта тебя тут не спасет. А еще 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, поменять ты его не сможешь, токен будет невалидный