3 ms·
> Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers). Since at some point the
by pygy_ 11y ago
> Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers).
Since at some point the loginkey was based on the unencrypted password that means that they either had to store the PW in clear (and fetch them from the DB) or generate the key at account creation and fetch it from the DB anyway.
A good strategy to check the token validity without reaching the DB is to sign it cryptographically. The loginKey can be $randomString+sign($randomString). The endpoint can check the signature before doing more costly things like a network request.
- hardwaresofton 11y agoYeah, I'm familiar, which is why I was surprised they had to deal with this at all -- most frameworks handle sessions like this for you automatically...
- jdmichal 11y agoIf you're going to signing, you may as well go all the way and just use an encryption + signing mechanism. Then you can store actual data in the token -- within reasonable transmission limits, of course.