Зачем ты делаешь await req.body или req.params? Чтобы получить айди того кто постит, пользователь должен быть зарегистрирован. Соответственно, ты получаешь эти данные например из токена
Для надёжности
Тогда уж await req.body.then((value) => await console.log(value))
Да, использую токены, а как мне тогда на бекенде вытащить нормально эти данные?
В токен пишешь айдишник пользователя На беке расшифровываешь токен и достаешь айдишник
Хм
такие данные обычно вытаскивают из БД
хотя некоторые из них могут лежать в сессии
А почему у тебя сначала сохраняется комментарий, а потом пост, причём у тебя если пост не найден, коммент уже сохранен в бд
Либо я чего то не понимаю
Await вообще роли не играет в твоём случае, поставь линтер и он укажет тебе что его лучше убрать, дабы не захламлять код
так проще заменять асинхронные выражения на синхронные не заморачиваясь какое из них какое
Если ты используешь JWT, ты можешь в payload засунуть какой нибудь идентификатор пользователя, будь то логин, спец. айди, почту и т.п. По идее, он не сможет его подменить потому что ты токен генерируешь с ключом. Я бы конечно ещё бы и захешировал токен по ключу, потому что иначе можно расшифровать base64. Так вот, когда к тебе приходит обратно токен от пользователя, в библиотеке jwt на это есть метод verify, который сольет тебе весь пейлоад
Хешировать каким-то bcrypt например?
Нет, нужна хеш функция которая хеширует по ключу, сейчас поищу
Hmac sha256 это дефолт
Hmac например можно
а кстати, если на ноде записать себе в куки и вытаскивать когда надо токен с куки?
В чем проблема положить айдишник пользователя? Ну сольют его, окей, использовать то его все равно не смогут никак
Вообще да, но просто если ключ короткий, можно посмотреть, какой алгоритм подписи у токена, и попробовать перебрать ключ. Плюс сам токен довольно длинный
И? Ну получишь ты _id: 123deaa1213fdebadb Че ты с этой инфой делать будешь?
Одним словом, пока без шифрований и прочего, я записал в пейлоад юзер айди, дальше как по правильному с ним быть? Как мне в нужное место получить этот айди с токена? Куками вот передавал, могу еще с фронта и еще масса вариантов, просто не знаю какой будет правильный) Я еще новичек.
1. Пользователь отправляет запрос на роут, например /login со своим логином и паролем 2. Ты проверяешь, что такой пользователь зареган, что все правильно, и генерируешь access_token и password_token 3. В access_token ты кладешь _id пользователя, который ты получил на этапе 2. Время жизни токена, например, 5 минут. 4. В refresh_token ты ничего не кладешь в payload, делаешь время жизни например 30 дней, и сохраняешь refresh_token в документ пользователя. 5. Возвращаешь access_token и password_token на фронт. Дальше, когда пользователь написал пост и нажал отправить, фронт отправляет запрос на условный /posts и вместе с телом запроса в header кладет токен 1. Ты на беке сначала проверяешь, что в header передан токен 2. Дальше, ты валидируешь его (что его не подделали, что время жизни не истекло) 3. Если все ок, то дешифруешь токен и получаешь _id юзера 4. Записываешь пост куда кладешь _id юзера из этапа 3. Если время жизни access_token истекло 1. Отправляешь ответ 401 на фронт 2. Фронт отправляет запрос с refresh_token на условный роут /refresh 3. Ты проверяешь, что refresh_token валидный, его время жизни не истекло 4. Если все ок, то генерируешь новую пару access_token|refresh_token и возвращаешь Соответственно, фронт получает обратно новый access_token и пробует уже с ним повторить запрос на /posts Если на этапе 2 время жизни refresh_token истекло или он не валиден Так же возвращаешь на фронт 401, фронт тогда редиректит юзера на страницу логина ну а дальше я уже описал access_token хранишь в сессион стораж, refresh в локал стораж. Чем меньше время жизни access_token и refresh_token - тем выше безопасность. В идеале, время жизни access_token секунд 15 Если положить refresh_token в сессион стораж то безопасность будет ещё чуть выше
Дальше, когда пользователь написал пост и нажал отправить, фронт отправляет запрос на условный /posts и вместе с телом запроса в header кладет токен Для этого кстати делаются мидлверы, да?
Да, только не нужно мутировать объект req. В мидлварах провалидировали, пропустили дальше, там уже в сервисе дешифровали токен для получения _id
Спасибо, все понял.
Обсуждают сегодня