22 lines
1.8 KiB
Markdown
22 lines
1.8 KiB
Markdown
# Weeklog
|
|
|
|
## Week 1 - Foundation
|
|
|
|
This week I built the initial foundation for the Auth Playground.
|
|
|
|
I set up a minimal Go backend using only `net/http`, implemented a `/health` endpoint, and connected it to a Svelte frontend through a Vite proxy. I also learned why Docker networking needs service names like `backend` instead of `localhost` between containers.
|
|
|
|
The main friction points were frontend tooling setup, ESLint configuration, and remembering small HTTP details like setting response headers before writing the body.
|
|
|
|
Next step: start Phase 2 with server-side sessions, HttpOnly cookies, login, logout, and a protected profile route.
|
|
|
|
## Week 2 - BFF Sessions + HttpOnly Cookies
|
|
|
|
This week I built the Phase 2 BFF auth flow: registration, login, server-side in-memory sessions, a protected profile route, and logout that destroys the session server-side. The frontend now mirrors the backend auth structure with a dedicated session playground, reusable UI primitives, Svelte 5 runes state, and no token storage in the browser.
|
|
|
|
The main learning points were why HttpOnly cookies are safer than browser-stored JWTs for classic web apps, how Go middleware can attach the current user to `context.Context`, and why cookie flags like `Secure`, `SameSite`, and `HttpOnly` have different local-dev and production tradeoffs. I also switched the original bcrypt plan to Argon2id and documented the reasoning.
|
|
|
|
The biggest friction points were Vite proxy rewriting `/api/*` incorrectly, Secure cookies not working over local HTTP, and making Attack Mode realistic without fighting modern browser blocking of `SameSite=None` without `Secure`.
|
|
|
|
Next step: finish Phase 2 polish if needed, then move to Phase 3 JWT with the explicit goal of understanding when JWT is useful and when browser apps should avoid it.
|