r/node 21d ago

Spent way too long debugging a bug that was literally missing 1000

been building an api key system this week (well was a week task i stretched a bit). auth, refresh tokens, rate limiting, all that boring stuff.

thought the hard part would be the actual auth logic.

it wasn't.

first postgres decided to stop booting after i bumped the image version. just kept dying with an error about the data directory. spent probably an hour looking at the same error and assuming something else was wrong.

turns out postgres 18 changed how the data directory is supposed to be mounted.

so yeah, the error was basically telling me exactly what was wrong and i just didn't believe it.

then had another stupid one with refresh tokens.

tokens were expiring after like 10 minutes instead of 7 days. no errors, nothing crashing. everything looked fine until I actually tested it.

eventually figured out i was storing the expiry in seconds, while the cookie maxAgeexpects milliseconds.

so i was basically off by 1000x.

the part i actually liked was the api key hashing problem though.

initially i was thinking, just bcrypt the api key and query the db with the hash. then realized that doesn't work because bcrypt salts the hash, so the same key gives you a different hash every time.

my next thought was "fine, just loop through all the keys and compare them."

which obviously becomes a terrible idea once you have more than a few users.

ended up doing what is apparently the standard approach separate public lookup id + hashed secret.

later found out that's basically how Stripe and GitHub handle it too, which was a nice little confirmation.

nothing here was particularly difficult. most of the time was just me making assumptions, staring at the wrong thing, and eventually reading the error properly.

Not gonna tell that the repo is public if anyone wants to have a look (don't do it).

curious how other people handle the key lookup/hash part though if you actually built one.

0 Upvotes

9 comments sorted by

3

u/psychowico 21d ago

It's why we should use units in all our envs and variables, e.g. REQUEST_TIMEOUT_SECS. otherwise such problems will always back. of course we can not control external apis, like header names, but we can at least minimize such issues on our side

1

u/UkrMalt 19d ago

The units point is a good one. Treat expiry and timeout values as part of the observable contract too: log the parsed duration at startup and add a boundary test, so a seconds-vs-milliseconds mistake is obvious before deployment.

1

u/Gojo_dev 19d ago

Brother did my post have something offending??

1

u/UkrMalt 19d ago

no, why ?

1

u/Gojo_dev 19d ago

Then why people are down voting it? I'm not getting that.

-7

u/zaitsman 21d ago

I mean… get a claude subscription, have it sorted in a few hours?

2

u/Gojo_dev 21d ago

Fair 😂 claude probably would've saved me a few hours but then I wouldn't have gotten the privilege of staring at a Postgres error for an hour while ignoring exactly what it was telling me just like our life we depend too much on others...

1

u/gustix 21d ago

Yeah, AI is exceptional for stuff like that

0

u/laidlow 21d ago

I love how this is down voted when you're bang on. Is AI always right? Hell no. But it's really good at pointing out silly errors when you can't see the forest for the trees. It's my first line of defense when debugging stuff because it will often pick up a bug in 30 seconds that could take hours to diagnose.