Closed ghost closed 6 years ago
@DavidNineRoc Brilliant, thanks.
If someone is having the same question, the tokens are stateless, which means they contain the information necessary to identify a user. The is no need to store them.
Can I get a confirmation that because they're stateless, upon a server migration, the tokens will not expire a users existing session. (with an expiration time of never, since this is a mobile app session.)
I don't need to copy anything over from storage/cache to move over to a new server?
@DavidNineRoc
@arianitu If you set the expiration time long enough and you have to make sure thatJWT_SECRET
is consistent, you can try the test.
I did the server migration and no sessions expired, the Stateless feature is very cool!
Cheers.
And how are the tokens blacklisted? How works the invalidate()
and logout()
methods? :thinking:
Hi, I have the same question. Will I have a huge directory full of invalidated tokens? Thanks.
@nelson6e65 @dhcmega The use of tokenis not required to store it, but when you use the blacklist feature, you need a storage material to save these. The blacklist, may be file, db, redis. depends on your system, so that the use of the cache will be more and more, and this is inevitable, unless you can find a better solution.
Hi @DavidNineRoc, thanks for your answer. Once a token expired and it's not renewable, will still be kept in the store? I think it would make sense to delete tokens that aren't valid anymore themselves.
Hello all,
That's not really a bug or an issue, but more a technical question. Where does
jwt-auth
store tokens on the server side? I mean they are not in the database, and I couldn't find them persisted on the disk..?Thanks
Environment