Expense Tracker — SQL-Enforced Multi-User Isolation

Registration accepts emails with no dot in the domain

The registration email format check is supposed to require a real domain with a dot in it (user@example.com). Right now it accepts garbage like user@localhost or user@nodotatall as a "valid" email -- letting obviously-malformed addresses into the system, which in a real deployment means bounced verification emails, unreachable accounts, and bad data quality that downstream features (password reset, receipts, notifications) all have to deal with.

Login always fails, even with the correct password

This is a total outage of the login flow. Every existing user is locked out -- POST /login returns 401 invalid email or password no matter what they type, because the password check itself is broken, not the credentials. Registration still works (Register issues a token directly, without going through Login), so this bug is invisible until a user's token expires (24h) and they try to log back in -- meaning it would likely reach production, pass a shallow "can I sign up?" smoke test, and only surface once real users get logged out, at which point it's a full incident: nobody can get back into their account.

Budgets can't be set on any of the built-in global categories

The seven built-in default categories (Food, Transport, Housing, Utilities, Entertainment, Health, Other) are what every new user starts with -- nobody has to create a category before they can log an expense. But now nobody can set a budget limit on any of them either: POST /budgets rejects every attempt to set a limit on a global category with "category does not exist or is not accessible," even though that same category works perfectly fine for logging expenses against. This defeats the budget feature for the overwhelming majority of users, who never get around to creating a custom category.

No way to fetch a single category by id

Every other resource in this API (expenses, budgets) supports fetching a single record by id -- categories is the only one where a client has to fetch the entire list just to check whether one category id is still valid, or get its current name (e.g. before rendering a single expense's category, or confirming a delete). Any frontend built against this API has to work around the missing endpoint with extra round trips.

No way to filter expenses by category

GET /expenses always returns every one of the caller's expenses. A user who wants to review just their "Entertainment" spending, or a client building a per-category expense view, has to fetch everything and filter client-side -- wasted transfer and work that grows without bound as a user's expense history grows.

No way to fetch a single budget by id

Budgets currently support List (all of the caller's budgets) and Delete (by id), but not fetching one specific budget by id -- so a client that wants to show or confirm a single budget's details (e.g. before editing it) has to fetch the entire list and search client-side.

Deleting your own expense can delete someone else's too

This is the worst possible category of bug for a financial-records product: silent, irreversible data loss across account boundaries. Any authenticated user who deletes any one of their own expenses will, in the same request, also delete every other expense they own -- and far worse, if they know or guess another user's expense id (sequential integer ids, trivially guessable), a single DELETE call against that id deletes that stranger's expense too, with no ownership check actually stopping it. A user reports "all my expenses vanished after I deleted one" -- that's this bug, and there is no undo.

Issued JWTs never expire

Every token this service issues is supposed to expire after TokenTTL (24 hours) -- that's the entire safety net if a token is ever leaked (a logged request, a compromised device, a browser history entry). Right now, issued tokens carry no expiry at all, so a token that leaks today remains a fully valid credential forever -- there is no way to force it to stop working short of rotating the JWT secret for every user at once. This silently removes a core security control without any visible symptom (everything looks like it's working -- tokens are issued, tokens are accepted -- right up until someone needs the expiry to have actually protected them).