feat(enroll): proxy agent binary download through the apps origin #39
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/proxy-agent-download-vapp-31"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The "+ New Device" dialog linked the Linux agent at {server_url}/meshagents/{id}, but /meshagents/ is served only by vervain-server and is session-gated. On a split-origin deployment that link 404s in the browser and 401s via curl, since the apps origin neither serves nor proxies it.
Add a same-origin /agent/{id} proxy: a custom axum route (wired via dioxus::serve, which serve_dioxus_application backs with the same static-asset, server-fn, SSR-fallback, and hot-reload setup dioxus::launch provides) streams GET {VERVAIN_SERVER_URL}/meshagents/ to the browser, forwarding the vervain_session cookie as the mc_session cookie vervain-server expects (mirroring the existing /meshsettings.ashx proxy). The body streams via Body::from_stream so a large binary never lands fully in memory, with the upstream content type passed through and Content-Disposition: attachment; filename=vervain-agent set.
MeshInstall gains agent_url, built from the browser origin (X-Forwarded-Host/Host plus X-Forwarded-Proto, default https) so the device-side curl snippet is reachable; it falls back to the relative /agent/ path when no host header is present. The dialog's download link and curl snippet both use it. This keeps the single-public-origin model VAPP-29 assumed regardless of how the ingress routes.
The desktop and wasm builds keep dioxus::launch; only the server build takes the custom-router path.
#VAPP-31
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
The "+ New Device" dialog linked the Linux agent at {server_url}/meshagents/{id}, but /meshagents/<id> is served only by vervain-server and is session-gated. On a split-origin deployment that link 404s in the browser and 401s via curl, since the apps origin neither serves nor proxies it. Add a same-origin /agent/{id} proxy: a custom axum route (wired via dioxus::serve, which serve_dioxus_application backs with the same static-asset, server-fn, SSR-fallback, and hot-reload setup dioxus::launch provides) streams GET {VERVAIN_SERVER_URL}/meshagents/<id> to the browser, forwarding the vervain_session cookie as the mc_session cookie vervain-server expects (mirroring the existing /meshsettings.ashx proxy). The body streams via Body::from_stream so a large binary never lands fully in memory, with the upstream content type passed through and Content-Disposition: attachment; filename=vervain-agent set. MeshInstall gains agent_url, built from the browser origin (X-Forwarded-Host/Host plus X-Forwarded-Proto, default https) so the device-side curl snippet is reachable; it falls back to the relative /agent/<id> path when no host header is present. The dialog's download link and curl snippet both use it. This keeps the single-public-origin model VAPP-29 assumed regardless of how the ingress routes. The desktop and wasm builds keep dioxus::launch; only the server build takes the custom-router path. #VAPP-31 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>