Building thoughtful software with AI.Notes from the systems behind the work.
Password and email login in my scheduling app verified the credential in one transaction and issued the session in another, so a reset landing in between still got a session. PIN login already carried a proof forward; now the others do too, and sign-up recovery got the same treatment.
Read moreThe gateway's admin sign-in ran a deliberately slow password hash twice just to pick a label. The commit that cut it to once also raised the hash cost, and it never tested whether the new cost fit the runtime's memory cap.
The scheduling app's sign-in box now routes email users to emailed codes and everyone else to short PINs, and rereading the change turned up a reset hint I'd reworded without closing, a session merge that changed a security marker, and a redirect check a double slash walks past.
The new sliding-session renewal re-signed a decoded token, the signer threw, and the guard turned that into a 401 for good tokens. I patched the middleware's refresh loop twice before moving renewal out of the way of login.
Both pricing buttons dumped people on the free dashboard after sign-in, so I started parking the plan choice in a short-lived cookie, reading it once on the way back, and sending paid picks to a checkout page that retries while the new account finishes setting up.
A signed link lets a supplier change one order with no account. The first version also put a fresh, non-expiring link on every row of my internal order list, and a closer read shows the supplier's edit becomes the real order right away.
Signup and login got the same words for everyone, but the same answer still leaked through response time, a lockout status code and a waited-on email step, plus a lowercase mismatch and unthrottled license-key endpoints. None of it is timed yet.
A button I added ends every session on an account, but reading the diff back showed the audit write runs ahead of the delete in the same try block, so a failed audit write can skip the revocation and still show the success message.
Wrong API keys made my auth service run a slow bcrypt check per candidate row, which guarded nothing for long random keys. I moved them to SHA-256 with constant-time compares, missed several paths on the first pass, and left a slow legacy branch and an untested format check behind.
A hardening commit keyed my rate limiter on an unchecked auth cookie read before any session validation, so a caller who changes the cookie lands in a fresh full bucket every time and the tightest login limits are the easiest to skip.
The move to hashed session storage kept a fallback that also matched the raw cookie value, so any row from a leaked table would have worked as a login until I pulled that branch out of every copy.
A new multi-tenant assistant service skips its token check for any path containing one word, and the stage right after it wakes that organization's container and forwards the request inside.
A tool server for an AI assistant was committed whose queries all filter by organization, but a failed token falls through to an environment default that stays on unless one exact mode string is set, and none of the deploy recipes set it.
The new front end kept its session as plain JSON in a cookie and the gate only checked the expiry, so the one way past it was a hand-written cookie; the waitlist route trusted its request body the same way.
The API read the user and organization straight out of bearer tokens without checking the signature, so anyone could have written their own. I swapped in real verification against the provider's keys, a pinned algorithm and a parsed issuer check, and review caught two more holes I'd left.
New accounts could bounce between my home page and a session-refresh route while a webhook caught up. I gave the wait one owner, a half-minute budget and an error page with a reason, and the tests are thinner than I'd like.
New accounts got a session token before their organization existed, so my access check's patient retries could never find it. I replaced the waiting with a check that asks the sign-in provider for a fresh token, added a fake database to test the access rules, and found a redirect loop and a few other holes rereading the diff.
A signup webhook builds the workspace but can never reach the session cookie, so my home page now waits, asks the login provider, and refreshes the session itself, and I still have two doubts about whether that refresh works.
After swapping my own key verifier for a hosted identity provider, every ingestion route still declares a required scope that nothing enforces, and revoked keys, rotation and attribution changed underneath it too.
Restoring a backup puts the old accounts back, including the one running the restore. The agent's first attempt saved only the admin's password; the second saved the whole account and its grants, and I walk through the gaps I can still see in the code, starting with the login rename and id reuse.
The first version of my second login path decoded signed tokens and trusted whatever user ID was inside; now it checks the signature and issuer, but the audience, the pinned issuer and a test with a real untrusted key are still open.
The first-run wizard check went from the root layout to the sign-in callback to a flag on the login profile, and only stopped misrouting people once the landing page and the wizard page asked the same rule about the same database row.