D
дак конфиг то писать все равно надо)
Я ж тебе его прислал практически целиком
Size: a a a
2021 January 27
D
я уставил композер с этим мантикором, запустил, но зарезлаася на конфиге и коннекту к нему, даже курл не проходит
Порты наружу просунул?
D
Порты наружу просунул?
да
D
да
Покажи конфиг
D
Я ж тебе его прислал практически целиком
да, ток оказалось что нужно rt)
NN
пока тупо выставил 100 лет в секундах, потому что в доках не нашёл такой возможности просто выставить undead
Раз в сто лет капитан летучего голландца сходит на берег, чтобы обновить сессию
DD
JwtModule.register({
secret: jwtConstants.secret,
signOptions: { expiresIn: '60s' },
}),
secret: jwtConstants.secret,
signOptions: { expiresIn: '60s' },
}),
так вообще не указывай expiresIn и кроме даты выдачи ничего в токене не будет. но вообще это не выход))
D
JWT без ротации токенов вообще не нужно. Потому что нужно либо в БД при каждом запросе лазать, либо токен делать бесконечным. И то, и другое сводит смысл использования JWT на нет
2021 January 28
NN
JWT без ротации токенов вообще не нужно. Потому что нужно либо в БД при каждом запросе лазать, либо токен делать бесконечным. И то, и другое сводит смысл использования JWT на нет
если апи с использование модели пользователя - так или иначе лазить в базу🤷
꧁岡
И снова жвт оказался не нужным
D
если апи с использование модели пользователя - так или иначе лазить в базу🤷
Разве? Зачем?
D
Что мешает хранить user_id в payload токена?
NN
Имхо, идея с джвт - годная, но не до конца додуманная.
как тезис с реализацией под бизнес-логику конкретного проекта - норм
Основная претензия к открытому тексту.
как тезис с реализацией под бизнес-логику конкретного проекта - норм
Основная претензия к открытому тексту.
D
Имхо, идея с джвт - годная, но не до конца додуманная.
как тезис с реализацией под бизнес-логику конкретного проекта - норм
Основная претензия к открытому тексту.
как тезис с реализацией под бизнес-логику конкретного проекта - норм
Основная претензия к открытому тексту.
Какая претензия? Если ты про то, что payload можно посмотреть, то это ерунда ж, потому что никто там ничего секьюрного не хранит, да и не нужно это
NN
Что мешает хранить user_id в payload токена?
Согласен - я не корретно сформулировал.
Если апи предполагает ту же проверку налияия и тд.
Вплоть до проверки наличия в базе того же id, если вдруг реально удаление
Если апи предполагает ту же проверку налияия и тд.
Вплоть до проверки наличия в базе того же id, если вдруг реально удаление
NN
Какая претензия? Если ты про то, что payload можно посмотреть, то это ерунда ж, потому что никто там ничего секьюрного не хранит, да и не нужно это
угу, но есть имплементация JWE
D
Согласен - я не корретно сформулировал.
Если апи предполагает ту же проверку налияия и тд.
Вплоть до проверки наличия в базе того же id, если вдруг реально удаление
Если апи предполагает ту же проверку налияия и тд.
Вплоть до проверки наличия в базе того же id, если вдруг реально удаление
Так id, очевидно, есть, иначе как он в токен мог попасть? А подменить его невозможно, иначе токен будет невалидным
NN
Но тогда токен слишком жирненьким становится)))
NN
Так id, очевидно, есть, иначе как он в токен мог попасть? А подменить его невозможно, иначе токен будет невалидным
Токен выдал - а пользователя после этого уже нет
D
Токен выдал - а пользователя после этого уже нет
Как ты можешь выдать токен юзеру, котого нет? При том, что access-токен обычно живёт пару минут