Working Signup/Auth System
Build a real signup, login, session, and protected route flow - not a form that only looks functional.
The route
13 steps to Done
- 01
Define auth requirements
Clarify exactly what the authentication system must do before building it.
Preview prompt + verify gate ▾ Hide ▴
Create a complete authentication requirements spec for this app. Include user signup, login, logout, session persistence, protected dashboard routes, validation rules, error states, loading states, duplicate email handling, and mobile behavior. Make clear that the implementation must be functional, not only visual.
- ✓ Signup requirements are defined
- ✓ Login requirements are defined
- ✓ Session persistence is included
- ✓ Protected route behavior is included
- ✓ Validation and errors are included
- 02
Choose auth method
Lock the auth mechanism so the AI does not mix approaches or silently pick something insecure.
Preview prompt + verify gate ▾ Hide ▴
Recommend and lock a single authentication method for this app. Compare email/password with JWT sessions, cookie sessions, magic links, and OAuth. Pick the simplest option that supports: session persistence after refresh, protected routes, and logout. State the final decision, the exact libraries or built-ins to use, and where tokens/sessions will be stored (httpOnly cookie vs localStorage) with the security tradeoff. Do not start implementing yet.
- ✓ Exactly one auth method was chosen
- ✓ Token/session storage location is specified
- ✓ Refresh persistence is addressed
- ✓ The choice supports logout and protected routes
- 03
Define the user database model
A real signup needs a real user record. Define the schema before generating any UI.
Preview prompt + verify gate ▾ Hide ▴
Define the user data model for authentication. Include: unique id, email (unique, lowercase), hashed password (state the hashing algorithm - bcrypt or argon2, never plaintext), display name, created_at, and any session/token fields needed. Specify the collection/table name, unique index on email, and exactly which fields are never returned to the client. Then create this model in the codebase.
- ✓ Email field is unique and normalized
- ✓ Passwords are hashed, never plaintext
- ✓ Password hash is never returned by any API
- ✓ Model exists in the actual codebase
- 04
Generate the signup page
Build the signup UI with all fields and states - the visible half of signup.
Preview prompt + verify gate ▾ Hide ▴
Build the signup page UI. Requirements: email field, password field, confirm password field, submit button with loading state, inline validation messages under each field, a top-level error area for server errors, a link to the login page, and mobile responsive layout. Wire the form state properly (controlled inputs, disabled submit while loading). Do not fake the submission - it will be connected to real logic next.
- ✓ Email, password, confirm password fields exist
- ✓ Submit button shows a loading state
- ✓ Inline validation messages render under fields
- ✓ Layout works at 375px width
- 05
Implement real signup logic
Make sure the form actually creates a user instead of only looking functional.
Preview prompt + verify gate ▾ Hide ▴
Implement the real signup logic for this app. Do not only create a visual form. The signup flow must actually create a user record, validate input, handle duplicate emails, show loading states, show error states, and redirect the user after successful signup. Requirements: email and password fields; confirm password field; required field validation; email format validation; password minimum length validation; duplicate email handling; loading state while submitting; success state after account creation; error state for failed signup; store user profile data; redirect successful signup to the dashboard; keep the user session active after signup; make the form responsive on mobile. Also create or update any required backend routes, database schema, client state, and protected route logic needed to make this real.
- ✓ Can a new user sign up?
- ✓ Does a duplicate email fail cleanly?
- ✓ Is the user redirected to the dashboard after signup?
- ✓ Is the session active immediately after signup?
- ✓ Do errors show clearly in the UI?
- 06
Generate the login page
Build login with real credential verification against stored users.
Preview prompt + verify gate ▾ Hide ▴
Build the login page and implement real login logic. Requirements: email and password fields; verify credentials against the stored hashed password; on success create the session and redirect to the dashboard; on failure show 'Invalid email or password' in the UI (do not reveal which field was wrong); loading state on submit; link to signup and to password reset; mobile responsive. The login must fail correctly for wrong passwords and unknown emails.
- ✓ Correct credentials log in and redirect
- ✓ Wrong password shows a visible UI error
- ✓ Unknown email shows the same generic error
- ✓ Submit button has a loading state
- 07
Add session persistence
Keep users logged in across refreshes - the most commonly faked auth behavior.
Preview prompt + verify gate ▾ Hide ▴
Implement session persistence. Requirements: after signup or login the session must survive a full page refresh and a browser tab close/reopen; add an app-load check that restores the authenticated user (e.g. verify token/cookie and fetch current user); show a brief loading state while the session is being restored so the UI does not flash to logged-out; implement logout that fully clears the session and redirects to login. Tell me exactly where the session is stored and how it is restored on load.
- ✓ Refresh on the dashboard keeps you logged in
- ✓ Closing and reopening the tab keeps you logged in
- ✓ Logout clears the session completely
- ✓ No logged-out flash while the session restores
- 08
Add protected dashboard routes
Actually block logged-out users - not just hide links.
Preview prompt + verify gate ▾ Hide ▴
Implement protected routes. Requirements: logged-out users who open any dashboard URL directly must be redirected to login; the check must happen before protected content renders (no flash of private data); after login the user is returned to the page they originally requested; backend endpoints that serve private data must also reject unauthenticated requests (401), because hiding frontend links is not protection. List every protected route and endpoint when done.
- ✓ Opening /dashboard while logged out redirects to login
- ✓ No flash of protected content before redirect
- ✓ Private API endpoints return 401 without a session
- ✓ After login you land on the originally requested page
- 09
Add validation and error states
Cover every input and failure path so auth feels trustworthy.
Preview prompt + verify gate ▾ Hide ▴
Audit the entire auth flow and add complete validation and error states. Requirements: required-field validation on all forms; email format validation; password minimum length (state the rule in the UI); confirm-password match validation; inline errors under each field; server errors displayed in a visible error area; disabled buttons while submitting; success feedback after actions. Produce a table of every form field -> validation rule -> error message so I can verify nothing is missing.
- ✓ Empty submits show required-field errors
- ✓ Bad email format is caught inline
- ✓ Short passwords are rejected with the rule shown
- ✓ Server failures show a visible error, not console-only
- 10
Add password reset flow
Complete the auth loop so locked-out users can recover.
Preview prompt + verify gate ▾ Hide ▴
Implement a password reset flow. Requirements: 'Forgot password?' link on login; a request-reset page that accepts an email and always shows a neutral confirmation (do not reveal whether the email exists); a reset page that accepts a secure single-use token and lets the user set a new password with confirm + validation; the new password must actually work on next login and the token must expire/invalidate after use. If real email sending is unavailable, print the reset link in the server logs or show it on screen in dev mode - but the reset itself must really change the password.
- ✓ Reset request shows a neutral confirmation
- ✓ Reset link/token opens the set-new-password page
- ✓ New password works on next login
- ✓ Old password stops working
- ✓ Token cannot be reused
- 11
Test auth edge cases
Attack the auth flow like a hostile tester before calling it done.
Preview prompt + verify gate ▾ Hide ▴
Act as a hostile QA tester on the auth system. Test and report PASS/FAIL with observed behavior for: signup with an already-used email; signup with mismatched confirm password; login with wrong password five times; direct URL access to /dashboard while logged out; refresh immediately after login; logout then browser back button (should not show private data); password reset with an expired/reused token; submitting all forms empty; and the whole flow at 375px mobile width. Fix every FAIL and re-run the table.
- ✓ All edge cases were actually executed
- ✓ Each result includes observed behavior
- ✓ Back button after logout shows no private data
- ✓ All FAILs were fixed and re-tested
- 12
Generate fix prompt for broken auth
Create a reusable repair prompt for when auth breaks later in the build.
Preview prompt + verify gate ▾ Hide ▴
Write me a reusable 'auth repair' prompt I can paste whenever authentication breaks in this app. It must instruct the AI to: re-verify signup creates real users; re-verify login validates against stored hashes; re-verify session restore on load; re-verify protected routes redirect; re-verify API endpoints enforce auth; check for the most common regressions (session not restored before render, guards removed during refactors, error states lost); and finish with the full edge-case PASS/FAIL table. Output only the prompt text so I can save it.
- ✓ The prompt covers signup, login, session, guards, and APIs
- ✓ It demands PASS/FAIL evidence
- ✓ It is self-contained and paste-ready
- 13
Final QA checklist
Verify the definition of done with evidence and close the flow.
Preview prompt + verify gate ▾ Hide ▴
Run the final QA pass against the definition of done: new users can sign up and a real record is created; users can log in and out; session persists after refresh; logged-out users cannot access protected pages; duplicate email fails cleanly; validation errors appear clearly; mobile layout works. For each item state DONE or NOT DONE with the exact evidence (what you did, what happened, what data changed). Fix anything NOT DONE and re-verify. No optimistic summaries.
- ✓ Every DoD item has evidence, not claims
- ✓ All NOT DONE items were fixed and re-verified
- ✓ The full flow was tested on mobile width