4 ms·

Yeah, and that's kinda sad because now you have to check a signature AND query a database!

Normal_gaussian 10y ago
Well you cache the blacklist and push updates, so it has no real performance cost. Just a tad more dev time
endymi0n 10y ago
s/database/in-memory-map/g should be fine - and suddenly it's pretty lightweight (subtracting service restarts and a highly available message bus of course :)
- sbergot 10y ago
  s/in-memory-map/cache-server/g if you happen to have a load balancer without sticky session.
  - zimbatm 10y ago
    In both cases there is a DB somewhere storing the list. The difference is that with the blacklist the server can keep an in-memory cache because it's so small. Sessions don't need to be invalidated atomically so the blacklist can be refreshed every couple of seconds.
vkjv 10y ago
Store it in a DB for persistence, but push it out to application memory. If for some reason you expect your blacklist to be very large (maybe, you have a massively popular API?), push a bloom filter of the blacklist instead of the actual list. Now, you (probably) only absorb the DB hit on blacklisted tokens.
throwaway2016a 10y ago
Two solutions: 1. As other posters pointed out. The blacklist is probably pretty small and can live in memory on your apps servers. If you have a distributed raft network or something to keep it in sync across nodes, even better. 2. You can avoid checking it against the DB unless the API call is sensitive (example: modifies data).
- floatboth 10y ago
  Yeah, of course you can do these things. I really meant to say, "there now exists server-side state for this" — I'm bothered by how existence of that state defeats the statelessness benefits of signature-based schemes, not the fact that I have to query a remote database. Oh, and also: "only store a blacklist" does not work if you want to provide the "revoke this app you gave access to a while ago and now it's spamming" functionality like in most social networks.

Well you cache the blacklist and push updates, so it has no real performance cost. Just a tad more dev time

s/database/in-memory-map/g should be fine - and suddenly it's pretty lightweight (subtracting service restarts and a highly available message bus of course :)

sbergot 10y ago
s/in-memory-map/cache-server/g if you happen to have a load balancer without sticky session.
- zimbatm 10y ago
  In both cases there is a DB somewhere storing the list. The difference is that with the blacklist the server can keep an in-memory cache because it's so small. Sessions don't need to be invalidated atomically so the blacklist can be refreshed every couple of seconds.

vkjv 10y ago

Store it in a DB for persistence, but push it out to application memory. If for some reason you expect your blacklist to be very large (maybe, you have a massively popular API?), push a bloom filter of the blacklist instead of the actual list. Now, you (probably) only absorb the DB hit on blacklisted tokens.

throwaway2016a 10y ago

Two solutions: 1. As other posters pointed out. The blacklist is probably pretty small and can live in memory on your apps servers. If you have a distributed raft network or something to keep it in sync across nodes, even better. 2. You can avoid checking it against the DB unless the API call is sensitive (example: modifies data).

floatboth 10y ago
Yeah, of course you can do these things. I really meant to say, "there now exists server-side state for this" — I'm bothered by how existence of that state defeats the statelessness benefits of signature-based schemes, not the fact that I have to query a remote database. Oh, and also: "only store a blacklist" does not work if you want to provide the "revoke this app you gave access to a while ago and now it's spamming" functionality like in most social networks.