feat(vite,next): forward allowedOrigins through bridge and Next handler - #350
Conversation
The Vite bridge and Next handler inherited devframe's loopback-only WS origin check with no way to widen it, so a devframe served same-origin by a non-loopback dev server (vite --host, containers, Codespaces, tunnels) rejected the RPC upgrade with 403 and the client sat stuck on 'connecting'. Add allowedOrigins to DevframeViteBridgeOptions (inherited by DevframeViteOptions) and CreateDevframeNextHandlerOptions, forwarded verbatim to initDevframe. Closes #348
◈ PR Lens
Architecture 2 components touched across 2 lanes. Data flow
The other flows — 1 sequence
Drill down
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
What
@devframes/vite'sdevframeViteBridge/devframeViteand@devframes/next'screateDevframeNextHandlerforwarded noallowedOriginstoinitDevframe, so their RPC WebSocket inherited devframe's loopback-only origin check with no way to widen it.Whenever the dev server is reached at a non-loopback origin —
vite --host, Docker/WSL/dev-containers, Codespaces, or a tunnel — the WS upgrade is rejected with HTTP 403, and aconnectDevframe()client sits onstatus: 'connecting'forever with no error surfaced.Change
allowedOrigins?: readonly string[] | WsOriginRegistry | falsetoDevframeViteBridgeOptions(inherited byDevframeViteOptions) and forward it toinitDevframe.allowedOriginstoCreateDevframeNextHandlerOptions, forwarded to its side-carinitDevframe.allowedOrigins.The auth gate remains the trust boundary;
falsedisables the origin check for a same-origin dev server that gates another way.Closes #348
This PR was created with the help of an agent.