Key point
Proof beats claims
Your repo should show working auth, not just say it has auth. A recruiter or judge should be able to clone it, add env values, run it, sign in, and see protected routes behave correctly.
Your to-do
Authentication
Your repo should show working auth, not just say it has auth. A recruiter or judge should be able to clone it, add env values, run it, sign in, and see protected routes behave correctly.
0 of 7 lessons done · proved by a submitted project with a public repository
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Create a sample env file with names only. Never paste real OAuth client secrets, JWT secrets, database passwords, or production URLs with credentials.
# .env.example
DATABASE_URL="your_database_url_here"
SESSION_SECRET="use_a_long_random_secret_here"
GOOGLE_CLIENT_ID="your_google_client_id_here"
GOOGLE_CLIENT_SECRET="your_google_client_secret_here"
NEXTAUTH_URL="http://localhost:3000"Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Use direct language. The goal is to help someone inspect your choices fast.
## Auth overview
Sign-in methods:
- Email and password
- Google OAuth
Protected routes:
- /dashboard requires a signed-in user
- /api/notes requires a signed-in user
- /login is public
Security choices:
- Passwords are hashed with bcrypt before storage
- Session is stored in an httpOnly cookie
- Cookie uses secure in production and sameSite=lax
- Server checks the session before returning private data
- Secrets are loaded from environment variables
How to test:
1. Run the app locally
2. Visit /dashboard while signed out. You should be redirected to /login
3. Sign in with a test account
4. Visit /dashboard again. You should see private content
5. Sign out and confirm /dashboard is blocked againDo not write “secure auth added” if your API routes still return private data without checking the user. Reviewers often test APIs directly, not only pages.
Also avoid committing screenshots that show real user emails, tokens, cookies, or OAuth secrets. Use a demo account and fake data.
Ask ChatGPT, Gemini, or Claude to review your README and test plan. Paste only non-secret code or file snippets.
Check what it returns. It may suggest fake package flags, wrong cookie names, or security claims your app does not actually implement.
Prompt:
Review this README auth section for clarity and missing security checks.
Do not add features I have not implemented.
Point out any claims that need proof in code.Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.