Two latent template-leftover bugs in vite.config.ts proxy that 404'd every useTokenTypes/useCreateToken/useManageToken/useDeleteToken call: - Default target was http://localhost:8000. Backend listens on :8080 (backend/config.yaml `server.port: 8080`, default registered in internal/config/config.go). Off-by-one-port silent for the whole Phase 14 cycle because Phase 14 didn't end-to-end-test. - `rewrite: (p) => p.replace(/^\/api/, '')` stripped /api before forwarding. But backend mounts routes UNDER /api via `r.Route("/api", ...)` (cmd/canary/main.go:322). So a request for /api/tokens/types got rewritten to /tokens/types, which backend doesn't serve — 404 page not found. Frontend axios uses baseURL `/api` and path `/tokens/types` → full URL `/api/tokens/types`. With these fixes the proxy now passes that through verbatim to http://localhost:8080/api/tokens/types, which is where chi actually mounts the route. dev.compose.yml: added VITE_API_TARGET=http://canary:8080 to the frontend container's env so the dev-compose path also works (inside the container "localhost" is the vite container, not the canary container — has to use docker DNS). Surfaced today when the operator manually eyeballed the landing page and SpeciesSection rendered "Could not load species catalog. Try again in a moment." (the descriptorsError branch in landing/index.tsx SpeciesSection). |
||
|---|---|---|
| .. | ||
| base64-tool | ||
| c2-beacon | ||
| caesar-cipher | ||
| canary-token-generator | ||
| dns-lookup | ||
| firewall-rule-engine | ||
| hash-cracker | ||
| keylogger | ||
| linux-cis-hardening-auditor | ||
| linux-ebpf-security-tracer | ||
| metadata-scrubber-tool | ||
| network-traffic-analyzer | ||
| simple-port-scanner | ||
| simple-vulnerability-scanner | ||
| systemd-persistence-scanner | ||