5 ms·
> Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly. You can solve this with a token/user blacklist. There a
by iEchoic 9y ago
> Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly.
You can solve this with a token/user blacklist. There are desirable (and undesirable) characteristics of using a blacklist instead of a whitelist, but you don't lose this capability.
- mattbroekhuis 9y agoHow do you share your blacklist across servers
- DanHulton 9y agoThe same way you share any of your other data across servers. Save it in a DB or Redis instance that all your servers can reach.
- eropple 9y agoAt which point you're hitting it on every request and since it'll be a nice, fast, indexed database lookup you might as well just use session tokens instead of a back-assward blacklist. Do the simplest thing that will work.
- iEchoic 9y agoAs I mentioned, blacklists have different characteristics, some of which are desirable. A blacklist of tokens is (for the vast majority of use cases) orders of magnitude smaller than a whitelist, which means they can often be replicated into memory for in-memory lookups on the webserver. This is a complex distributed systems topic, and there are applications for both.
- eropple 9y agoThere are cases where a blacklist totally makes sense, I will agree with you on that. "I can access this thing" are totally not that for the 99.9% case. Do the simplest thing that will work--and the simplest thing so very rarely involves public-key cryptography!