curo1305
d423bea134
- backend-net (internal: true): db ↔ backend ↔ frontend reverse proxy - frontend-net: frontend only; single host port binding (80 prod / 5173 dev) - Remove ports: from db (5432) and backend (8000) — unreachable from host - Security auditor: hard rule to never add host ports to db or backend Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
47 lines
3.9 KiB
Markdown
47 lines
3.9 KiB
Markdown
# TODO
|
||
|
||
## UX/UI — Penpot setup
|
||
|
||
- [ ] **Spin up Penpot LXC** — separate LXC container on the server (~2–4 GB RAM), Docker Compose from https://github.com/penpot/penpot; expose via subdomain behind nginx proxy manager
|
||
- [ ] **Create Penpot project** — register on the self-hosted instance, create project `destroying_sap`, create initial design file
|
||
- [ ] **Generate Penpot access token** — Profile → Access tokens; used by the `ux-designer` agent via WebFetch REST API calls
|
||
- [ ] **Decide on UI component library** — shadcn/ui (recommended: Tailwind-based, unstyled accessible primitives, white-label friendly) vs MUI vs other; decision affects both Penpot design system and frontend implementation
|
||
- [ ] **Connect ux-designer agent** — confirm Penpot API reachable, provide instance URL + token to agent at session start
|
||
|
||
## Auth / session security
|
||
|
||
- [x] **8-hour JWT expiry** — `ACCESS_TOKEN_EXPIRE_MINUTES = 60 * 8`; no permanent login
|
||
- [x] **RS256 JWT signing** — 4096-bit RSA asymmetric keys; `iat` claim included; generate keys with `scripts/generate_jwt_keys.py`
|
||
- [ ] **No refresh tokens** — refresh token flow not implemented; if added later, must use `httpOnly` cookies and rotation
|
||
- [ ] **`httpOnly` cookie migration** — currently storing JWT in `localStorage` (XSS-exposed); migrate to `httpOnly` cookie when hardening for production
|
||
|
||
## App permissions
|
||
|
||
- [ ] **Permissions registry** — admin-managed table that controls which apps each user can access. Schema: `user_app_permissions (user_id FK, app_key)`. Admin UI lets the admin grant/revoke per-app access per user. The Apps page only shows apps the current user has been granted access to.
|
||
|
||
## Frontend features
|
||
|
||
- [x] **Logout button** — visible when logged in, clears token and redirects to `/login`
|
||
- [x] **Profile page** (`/profile`) — shows personal information for the logged-in user
|
||
- [x] **Edit & save profile** — form to update personal details, stored in a dedicated `profiles` table (separate from `users`, same PostgreSQL container)
|
||
|
||
## App container architecture (future)
|
||
|
||
Design decision: each installable app (billing, PDF, email, etc.) runs in its own isolated Docker/Podman container, spawned and managed by the backend via the Docker API. Key rules to implement:
|
||
|
||
- [ ] **Docker socket proxy** — backend must never mount `/var/run/docker.sock` directly; use `tecnativa/docker-socket-proxy` on an internal-only network, with only the required API endpoints whitelisted (CONTAINERS, IMAGES, NETWORKS, POST). Raw socket access = root on the host.
|
||
- [ ] **Network isolation per app** — each spawned app container gets its own Docker bridge network; app containers never talk to each other directly; only the backend can reach them
|
||
- [ ] **No privileged app containers** — all spawned containers run without `--privileged`, without extra capabilities, with resource limits (CPU, memory)
|
||
- [ ] **Image allowlist** — backend may only spawn containers from a pre-approved image list; never pull or build arbitrary images at runtime
|
||
- [ ] **Consider Podman** — evaluate rootless Podman as replacement for Docker daemon; daemonless model eliminates the socket entirely; Docker SDK compatible
|
||
|
||
## Infrastructure
|
||
|
||
- [x] **Docker port hardening** — only port 80 (prod) / 5173 (dev) exposed on the host via `frontend-net`; backend and db have no host port bindings and sit on `internal: true` `backend-net`
|
||
|
||
## Infrastructure (existing)
|
||
|
||
- [x] **Rootless containers** — run backend and frontend containers as non-root users (add `USER` directive to Dockerfiles, map UID/GID appropriately)
|
||
- [ ] **Persistent storage** — ensure database data, config files, and any uploaded assets survive container restarts and rebuilds (named volumes, bind mounts for config)
|
||
- [ ] **Docker development workflow** — document and streamline the full dev loop: hot reload, one-command startup, migration handling, seed data, and how to attach a debugger
|