Почему dispatch нельзя использовать в потоке кода при отрисовке компонента?

Спасибо, а по какой логике срабатывает эффект, когда мы в массив добавляем dispatch?
Мы же ссылаемся на useDispatch, а не какое-либо значение
Когда нужно его добавлять в массив, а когда нет?

useEffect(() => {
        dispatch(setToken(token))
}, [dispatch])

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS, да, рефреш живет в http only cookie и его всегда можно прочитать при любом запросе, он не удаляется
А аксес токен добавляется только в те fetch, где прописан заголовок Authorization

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS, допустим, я сделал, как в примере, у меня сработал next() и передал дальше данные токенов
Как мне их отправить клиенту?
У меня десятки роутов и в каждом из них нужно повторять код на проверку
if(request.apiToken)
что бы отправить не просто
res.status(200).json(data)

А что-то вроде такого?

res.cookie('refreshToken', request.apiToken)
res.status(200).json({data, accessToken: request.accessToken))

Но мне тогда в каждом роуте нужно будет это повторять, а хотелось бы только в одном месте эту проверку прописать и что бы работало для всех роутов

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS, а как тогда реализуют аутентификацию через токены?
Как их обновляют все, когда запрос идет для получения данных, а аксесс токен закончился и нужно обновить токены?

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS,
Немного не понял про это, в поисковике тоже не особо статей
Подскажите пожалуйста, что значит
res.body + "modified"; и по какому принципу это работает?

function modify(req, res, next){
  res.body = res.body + "modified";

  next();
} и положите туда все свои "повторяющиеся хотелки"

Что-то похожее я видел в виде, что мы просто делаем

res.body.tokens = tokens
next()

И у нас вроде следующий обработчик в мутированном req уже увидит req.tokens

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS, но это middleware для проверки токенов
А вот как быть в случае, если нам нужно токены обновить и при этом отдать данные еще, т.к. запрос был для получения данных, а обновления токенов упали прицепом

Т.е. мы в middleware проверки токенов еще должны обновить токены и при этом после пустить дальше на роут для обработки запроса данных, а после отдать данные и новые токены

До этого момента я всегда отдавал данные в виде
res.status(200).json(data)

Но в данной ситуации мне кажется, что придется теперь все ответы переписать под шаблон в виде

res.status(200).json({
data,
access_token,
message,
error
})

Но это так же ляжет доп. нагрузкой на логику в каждом запросе на клиенте, что теперь нужно будет всегда проверять на наличие ключа access_token, что если он есть, то обновить его на клиенте

Как правильно отдавать обновленные токены в роутах?

Daemon23RUS,
Если аксес токен закончился, но рефреш еще жив, то
1) проверяем рефреш токен на валидность и после с его записью в БД, что это тот же токен
2) если он совпал, то генерируем два новых рефреш и аксес токена
3) записываем в бд новый рефреш токен
4) отдаем данные и рефреш + аксес токены

Как правильно отдавать обновленные токены в роутах?

Как обрабатывать такой запрос в том случае, если аксес токен закончился?

Ситуация, что у нас закончился аксес токен, но рефреш еще жив.
Мы в middleware обновляем запись в таблице с рефреш токенами и создаем новый аксес токен

Но где и как нам их возвращать пользователю?
Из роута api/user или как-то до него можно это сделать отдельно, а после уже прислать отдельно ответ с api/user?

Суть моего вопроса была в том, можно ли, чтобы в каждом роуте api/user, api/friends, api/contacts и т.д. избежать массового добавления кода по типу

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   if(req.refreshToken) res.cookie('refreshToken', req.refreshToken, { httpOnly: true })
   if(req.accessToken) {
      res.status(200).json({data, access_token: `Bearer ${req.accessToken}`})
      return
   }
   res.status(200).json({data})
}

Вместо простого

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   res.status(200).json({data})
}

Где мы до этого в middleware проверяли токены и если их обновляли, то добавляли в reqи делали next()

Как правильно отдавать обновленные токены в роутах?

При логине я отправляю через куки рефреш токен и в обычном сообщении аксес токен
Записываю на клиенте в хранилище аксес токен и прикрепляю его при запросах в хедер авторизейшн

Но после возникла проблема, когда я начал создавать роуты, где нужно быть авторизованным
Как с ними делать обновление токенов?

У меня выходит так, что в каждом таком роуте теперь приходится отправлять не просто
res.status(200).json(data)

А уже что-то подобное

res.cookie('refresh_token', tokens.refresh_token, { httpOnly: true })
res.status(200).json(
{
data,
access_token: `Bearer ${tokens.access_token}`
}
)

Т.е. каждый роут приходится сопровождать
Аксес токеном, если мы его обновили
access_token: `Bearer ${tokens.access_token}`

И так же рефреш токеном

res.cookie('refresh_token', tokens.refresh_token, { httpOnly: true })

У меня ответ получается вместо 1 строки уже 5, где 4 с токенами строчки везде одинаковые по всем роутам

И я хотел бы вынести эту логику с обновлением токенов из роутов в middlewareили как-то еще

Как уникально идентифицировать устройство пользователя, кроме user-agent?

Refguser, каким инструментом это лучше делать в node js?

Как уникально идентифицировать устройство пользователя, кроме user-agent?

Почитал про него, но там пишут, что он всё равно будет меняться со временем

Если я не ошибаюсь, то на сервере сами задают куку с уникальным значением, которое и будет отвечать за уникальность устройства?

Задача, сделать поле по которому будет искать наличие токена для этого устройства

Как уникально идентифицировать устройство пользователя, кроме user-agent?

Как я понял, они все ненадежные и могут динамический меняться

Если я не ошибаюсь, то на сервере сами задают куку с уникальным значением, которое и будет отвечать за уникальность устройства?

Задача, сделать поле по которому будет искать наличие токена для этого устройства

Как запушить данные после изменения remote set-url?

Сергей Кузнецов, понял, спасибо )

Как запушить данные после изменения remote set-url?

Сергей Кузнецов, подскажи пожалуйста, это всё из-за того, что первый коммит в ветку main выдает ошибку, а остальные проходят нормально после мерджа другой ветки в main и git pull —allow-unrelated-histories origin main?

Почему история теряется?
И как правильно делать первые шаги до пула в такой ситуации?
Или так и делается, что пушится другая ветка, мерджится и делается пул с разрешением историй?

Как запушить данные после изменения remote set-url?

Попытался запушить в другую ветку, но он не создал ее, а выдал ошибку

git push origin test
error: src refspec test does not match any

Как правильно проверять и обновлять refresh jwt?

Петр, подскажи пожалуйста, при генерации нового access_tokenнужно же и новый refresh_token создавать, верно, а то мне показалось, что с твоих слов он не пересоздается?

А сам токен в нем хранить не надо?
Я думал в таблице идет поиск по user_id AND token
Refs (id, userId, validFrom, validTo)

Так, а при выходе, как мы потом сюда же запишем новый токен?
Или просто ищется любая запись с user_id у которой validTo=now и записывается в нее?

Но как быть, если злоумышленник зашел по украденному токену?
У нас пользователь разлогинется через 5 мин, но если он зайдет снова, у него создастся тогда новая запись refresh_token, а та, которую украли, так же останется рабочей и будет обновляться

Как правильно проверять и обновлять refresh jwt?

Спасибо, подскажи еще пожалуйста

Получается при обновлении токенов, делать запрос по сходству user_idAND refresh_token?

А как быть при выходе из аккаунта, нужно стирать запись в БД или просто удалять в колонке значение refresh_tokenи при следующем логировании искать user_idи вписывать новое значение refresh_token?

И если у нас два и более устройств, как этот момент учесть?

Почему я не могу подключить к контейнеру на localhost?

сергей кузьмин, docker run -dp 127.0.0.1:5173:5173 react-test
Запускал такой командой, всё равно не видит localhost:5173

Почему я не могу подключить к контейнеру на localhost?

Everything_is_bad, подскажи пожалуйста, что я запускаю не так?

Почему я не могу подключить к контейнеру на localhost?

Everything_is_bad, все сделал, как тут указано
https://docs.docker.com/get-started/02_our_app/

Только поменял порты
docker run -dp 127.0.0.1:5173:5173 react-test
Выше на изображении виден этот процесс