Login always fails, even with the correct password

Nobody has started this yet — be first.

Business impact

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.

Problem

CheckPassword's call to bcrypt.CompareHashAndPassword has its two arguments swapped -- it's passing the plaintext password where the library expects the bcrypt hash, and vice versa.

Current behavior

Logging in with the exact correct email and password still returns 401 invalid email or password, every single time.

Expected behavior

CheckPassword(hash, plain) returns true exactly when plain, once hashed, matches hash.

Steps to reproduce

Expected: 200 with a token.

Actual: 401.

Why this matters

bcrypt.CompareHashAndPassword(hashedPassword, password) has a specific, non-symmetric argument order -- the first argument must already be a bcrypt hash, or the function can't even parse it and returns a non-nil error (which CheckPassword collapses to false). Swapping the arguments is a realistic copy-paste/argument-order mistake that compiles cleanly (both parameters are []byte) while being 100% wrong at runtime, for every single login attempt, always.

Suggested approach

Check bcrypt.CompareHashAndPassword's documented parameter order against how CheckPassword's own two parameters (hash, plain) are named and used when calling it.

Acceptance criteria

Login with the correct password succeeds (200, token returned).
Login with an incorrect password still correctly fails (401) -- this must not accidentally become "always returns true."
Registration is untouched (it doesn't call CheckPassword at all).

Verification

go test ./practicetickets/... -run TestTicket04 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/login-password-check-swapped

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/login-password-check-swapped

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Expense Tracker — SQL-Enforced Multi-User Isolation

A production-style multi-user expense tracker in Go where the authorization boundary between one user's financial data and everyone else's is a literal SQL `WHERE id = $1 AND user_id = $2` clause -- not an application-layer check -- so a single flipped operator or dropped predicate is a real, silent cross-account data breach, not a cosmetic bug.

Fork on GitHub

Download

Setup

Expense Tracker — SQL-Enforced Multi-User Isolation

git clone <your-fork>
cd expense_tracker
docker compose up --build   # postgres (host port 5434) + app (host port 8082)

auto-applies on first boot via Postgres's mechanism, seeding the seven global default categories (ids 1-7). The compose project is named , so it won't collide with sibling projects on the same machine. Health-check on gates 's startup so the API never starts before the schema exists.