Follow-up from #379 (Copilot review pass 11).
The Phase 1 cors-proxy in #379 routes everything through a single global `/proxy` endpoint. That works cleanly for:
- Single-user mode: pod is at `/` so `/proxy` is part of the (single) pod's URL space, gated by `/proxy.acl`.
- Subdomain mode: each pod has its own origin (`alice.example.com`), so `/proxy` resolves into that pod's namespace per-host.
It does not work cleanly for path-based multi-pod (the default `createServer` mode without `--single-user` or `--subdomains`):
- Pods live at `//...`
- `/proxy` sits outside every pod
- Pod owners can't write a `.acl` to control proxy access — only the server operator can (by writing root-level `/.acl` or `/proxy.acl`)
- A genuine "each user gets their own gated proxy" deployment isn't possible
Options
A. Match `//proxy` in path-based mode
`isCorsProxyRequest()` would need to extract the pod segment and recognize a tail of `/proxy`. The preHandler then runs WAC against `//proxy` so each pod owner controls their own proxy via their pod's ACL hierarchy.
Trade-off: more code, more cases (the global `/proxy` fallback for non-pod-paths still needs a story), and slightly more surface for path-confusion bugs.
B. Document that `--cors-proxy` is single-user / subdomain only
Smaller change; ship Phase 1 as-is and add a note to the README and `bin/jss.js` boot banner. Path-based-pod operators would need to wait for the per-pod work or run subdomain mode.
C. Make the route configurable
`--cors-proxy-path /api/proxy` so operators can route however suits their deployment. Still leaves the per-pod ACL story unsolved in path-based mode.
Refs
Follow-up from #379 (Copilot review pass 11).
The Phase 1 cors-proxy in #379 routes everything through a single global `/proxy` endpoint. That works cleanly for:
It does not work cleanly for path-based multi-pod (the default `createServer` mode without `--single-user` or `--subdomains`):
Options
A. Match `//proxy` in path-based mode
`isCorsProxyRequest()` would need to extract the pod segment and recognize a tail of `/proxy`. The preHandler then runs WAC against `//proxy` so each pod owner controls their own proxy via their pod's ACL hierarchy.
Trade-off: more code, more cases (the global `/proxy` fallback for non-pod-paths still needs a story), and slightly more surface for path-confusion bugs.
B. Document that `--cors-proxy` is single-user / subdomain only
Smaller change; ship Phase 1 as-is and add a note to the README and `bin/jss.js` boot banner. Path-based-pod operators would need to wait for the per-pod work or run subdomain mode.
C. Make the route configurable
`--cors-proxy-path /api/proxy` so operators can route however suits their deployment. Still leaves the per-pod ACL story unsolved in path-based mode.
Refs