Support serving Yuvomi under a sub-path (BASE_PATH), e.g. for Home Assistant Ingress

[wt19]

Hi, and thanks for Yuvomi – it’s a really well thought-out project.

Use case
I run Home Assistant OS and would like to package Yuvomi as a local Home Assistant app (add-on). Home Assistant can embed an app in its sidebar via Ingress: the app is then served through Home Assistant’s own authenticated proxy under a path like /api/hassio_ingress//. The big benefit is that the whole household can open Yuvomi from the Home Assistant companion app, both at home and remotely, without exposing another port or setting up a separate reverse proxy. It’s the same situation as any reverse-proxy setup like https://home.example.com/yuvomi/.

What happens today
Yuvomi assumes it lives at /. Behind a sub-path, the frontend requests /api/v1/..., /js/... and so on at the origin root, which (in the Home Assistant case) hits Home Assistant’s own /api/ instead of Yuvomi. Rewriting every path in a proxy with sub_filter is possible in theory, but fragile and likely to break with every release.

Proposal
An optional BASE_PATH environment variable (default: empty = current behaviour), used for:

• static assets, API calls and module asset URLs in the frontend
• redirects and the session cookie path
• the PWA manifest (start_url, scope) and the service worker scope

For Home Assistant, a static env var is enough: the ingress path is fixed per installation and the add-on can read it from the Supervisor API at startup and pass it in.

Things I’m aware of

• Under Ingress, the origin is Home Assistant’s origin, so the Origin/CSRF check would need to accept requests arriving at BASE_PATH via the proxy (TRUST_PROXY is already there).
• Push notifications and PWA install from inside the Home Assistant app are not expected to work. Direct access on port 3000 stays the way to use the PWA on phones.
• No change at all for anyone who doesn’t set BASE_PATH.

If this sounds reasonable, I’m happy to test pre-releases in a Home Assistant setup and share the add-on wrapper.

Thanks!

[ulsklyc]

@wt19 Thanks - a clear use case, and your list of what it touches is accurate.

Where it stands: Yuvomi assumes it lives at /, as you found. The manifest's start_url and scope, the service worker scope and the session cookie path are all /, and the frontend addresses its own files and the API with absolute paths - well over a thousand of them. So a sub-path is not a switch but a change across the whole frontend, and the service worker cache and the CSRF origin check would have to follow it. A proxy rewrite with sub_filter would indeed break with the next release.

What works today without a sub-path is a host of its own behind your reverse proxy (for example yuvomi.home.example.com). Embedding that in the Home Assistant sidebar as a web page panel will not work either, because Yuvomi only allows itself to be framed by its own origin. So today it is a separate address, opened in the browser or as the installed app, with Yuvomi's own sign-in.

Nothing is decided yet and there is no date.