Fix Fake Auth
Your login 'works' but nothing is real: convert visual-only auth into persisted users, sessions, and guards.
The route
6 steps to Done
- 01
Diagnose what is fake
Map exactly which parts of auth are theater before rebuilding.
Preview prompt + verify gate ▾ Hide ▴
Audit the current auth implementation and report precisely what is real vs fake: Does signup write a user record (show where)? Does login verify a password against a stored hash or accept anything? Where does auth state live and does it survive refresh? Are routes guarded before render? Do backend endpoints check the session? Output a table: component -> current behavior -> required behavior.
- ✓ Signup persistence verified in the database
- ✓ Login verification logic inspected
- ✓ Route and API guards checked
- 02
Implement real user persistence
Signup must create actual users with hashed passwords.
Preview prompt + verify gate ▾ Hide ▴
Fix signup to be real. Requirements: a user model with unique email and bcrypt/argon2-hashed password; the signup endpoint validates input, rejects duplicate emails with a visible UI error, creates the record, and starts the session; the password hash is never returned to the client. Prove it: sign up, show the stored record (hash present, no plaintext), and show the duplicate-email failure.
- ✓ Record exists after signup with hashed password
- ✓ Duplicate email shows a UI error
- ✓ No plaintext password anywhere
- 03
Implement real credential verification
Login must check the password, not just navigate.
Preview prompt + verify gate ▾ Hide ▴
Fix login to verify credentials. Requirements: the login endpoint looks up the user by email and compares the password against the stored hash; wrong password and unknown email both show 'Invalid email or password' in the UI; success creates the session and redirects; loading state during submit. Prove it with three attempts: correct (succeeds), wrong password (fails visibly), unknown email (fails visibly).
- ✓ Wrong password is rejected
- ✓ Unknown email is rejected with the same generic message
- ✓ Correct login creates a session
- 04
Implement session persistence and logout
Auth state must live somewhere durable, restored on load.
Preview prompt + verify gate ▾ Hide ▴
Fix sessions. Requirements: on login/signup store a session token (httpOnly cookie preferred, or localStorage with the tradeoff stated); on app load, restore the user by verifying the token before rendering protected UI, with a loading state; logout clears the token client- and server-side and redirects. Prove it: log in, refresh (still in), close/reopen tab (still in), logout then back button (locked out).
- ✓ Refresh preserves the session
- ✓ Restore happens before protected render
- ✓ Logout plus back button exposes nothing
- 05
Enforce guards on routes and APIs
Protection must exist in two layers: router and backend.
Preview prompt + verify gate ▾ Hide ▴
Fix protection. Requirements: a route guard that redirects logged-out users from every protected page before rendering content; every backend endpoint serving private data verifies the session and returns 401 otherwise; list every protected route and endpoint and its guard. Prove it: open protected URLs logged-out (redirect, no content flash) and call private APIs without a token (401).
- ✓ Direct URL access redirects without a content flash
- ✓ Private APIs return 401 without a session
- ✓ The protected list covers everything private
- 06
Full auth verification
Run the complete honest test suite on the rebuilt auth.
Preview prompt + verify gate ▾ Hide ▴
Run and report PASS/FAIL with evidence: fresh signup creates a record; duplicate signup fails visibly; wrong password fails; login succeeds; refresh persists; protected URL logged-out redirects; private API logged-out returns 401; logout clears; back button after logout shows nothing private; forms validate empty input; mobile layout works. Fix all failures and re-run.
- ✓ All eleven cases executed with observed results
- ✓ No case passed on assumption
- ✓ All failures fixed and re-verified