8 ms·

Why do you need a db call for api request when you can just cache session data?

andrewxdiamond 7y ago
JWT are effectively that, a signed token that contains the session information. You could build a session cache, either in memory or out of process, but it would still be more work than the token approach
dyeje 7y ago
Typically, before stuff like JWT was popular, you would store a session in the db and the session id in a cookie. Then you would hit the db each request to check if the session was valid.
- ossworkerrights 7y ago
  Well not really. Storing session data in the db can hit your performance pretty bad. Storing them in mem is a better option.
  - latortuga 7y ago
    These are not mutually exclusive options. Redis is a database and runs in memory.
    - ossworkerrights 7y ago
      Actually no, it’s an “in-memory data structure store, used as a database, cache and message broker.”.
  - dyeje 7y ago
    Yea, that's why people moved to auth headers.
ninjakeyboard 7y ago
In memory caches have scalable concerns and require sticky load balancer. You'd need to decentralize the cache (eg create a db for the session information) to allow horizontal scaling of services so this approach is generally considered old-school. JWT has its own slew of problems, most of them are temporal (eg invalidation of all sessions), usability (eg short expiry), or additional security vectors (many poor JWT implementations, accidentally authenticating invalid tokens w/o signing, careless storage of readable values)
- ossworkerrights 7y ago
  Hmm never had an issue with in memory caching and scalability (except in the old days of memcache). One can send a unique and hard to guess pair of identifiers and drop the lb stickiness. anyway depends on the use case, but i feel like given the symptoms you describe there are a few other ways of doing it without jwt.
  - ninjakeyboard 7y ago
    For sure - they're just considerations/complexities if you need to quadruple your service infrastructure for black friday or what not. I don't feel JWT is often appropriate - I wrote one of the early scala implementations so have seen the lifecycle of a security library.
rblatz 7y ago
I’ve found that writing starless services makes my life significantly easier. Also I may need to query several apis to render a single page. Each one needs to know who is calling it.

JWT are effectively that, a signed token that contains the session information. You could build a session cache, either in memory or out of process, but it would still be more work than the token approach

dyeje 7y ago

Typically, before stuff like JWT was popular, you would store a session in the db and the session id in a cookie. Then you would hit the db each request to check if the session was valid.

ossworkerrights 7y ago
Well not really. Storing session data in the db can hit your performance pretty bad. Storing them in mem is a better option.
- latortuga 7y ago
  These are not mutually exclusive options. Redis is a database and runs in memory.
  - ossworkerrights 7y ago
    Actually no, it’s an “in-memory data structure store, used as a database, cache and message broker.”.
- dyeje 7y ago
  Yea, that's why people moved to auth headers.

ninjakeyboard 7y ago

In memory caches have scalable concerns and require sticky load balancer. You'd need to decentralize the cache (eg create a db for the session information) to allow horizontal scaling of services so this approach is generally considered old-school. JWT has its own slew of problems, most of them are temporal (eg invalidation of all sessions), usability (eg short expiry), or additional security vectors (many poor JWT implementations, accidentally authenticating invalid tokens w/o signing, careless storage of readable values)

ossworkerrights 7y ago
Hmm never had an issue with in memory caching and scalability (except in the old days of memcache). One can send a unique and hard to guess pair of identifiers and drop the lb stickiness. anyway depends on the use case, but i feel like given the symptoms you describe there are a few other ways of doing it without jwt.
- ninjakeyboard 7y ago
  For sure - they're just considerations/complexities if you need to quadruple your service infrastructure for black friday or what not. I don't feel JWT is often appropriate - I wrote one of the early scala implementations so have seen the lifecycle of a security library.

rblatz 7y ago

I’ve found that writing starless services makes my life significantly easier. Also I may need to query several apis to render a single page. Each one needs to know who is calling it.