2 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	185a69c806	fix(web/plugins): a plugin's interface loads again, instead of an empty panel ... Two separate things had to be wrong for this, and both were. The frame's own policy locked it out. Plugin UIs moved to their own origin so a plugin cannot act as the logged-in operator, and the plugin origin names the console as the only page allowed to frame it. It built that name from the incoming request — but Nitro hands the app a synthetic request with no TLS socket, so an HTTPS console reads back as `http:`. The header said `frame-ancestors http://host:47992` while the operator was on `https://host:47992`, and the browser refused the frame outright (ERR_BLOCKED_BY_RESPONSE). Nothing on screen said so; the reason was only in devtools. The scheme now comes from the listener's own TLS state, stamped at bind time, with x-forwarded-proto winning when something in front terminated TLS for us — the one case where the browser's scheme is not ours. And the port was shut. 47993 was added to the firewall definitions, but an already-open firewall does not pick a new port up: ufw expands an app profile into rules when you allow it and keeps those, so editing the profile on upgrade changes nothing, and firewalld needs a reload. Every upgraded Linux host kept a 47992-only rule, silently. The packages now notice on upgrade and print the one command that fixes it, without touching the running firewall. The NixOS module and the container image never learned the port at all; both now open it. Also: the console no longer mounts the frame while it is still checking whether that origin is reachable. A firewalled port drops rather than refuses, so the check hangs for the browser's whole connect timeout, and mounting meanwhile is exactly the empty panel with no explanation. The card that follows now names both causes it can be — an untrusted certificate for that port, or a closed one — because from a browser the two are indistinguishable. The rule is now a pure function with tests, since its failure mode is a well-formed header that only a browser rejects. Verified on glass against home-worker-5 (.21) and its ROM Manager plugin: the frame was refused before, renders the plugin's UI after.	2026-08-06 22:33:57 +02:00
enricobuehler	defdfbdb58	fix(security): plugin UIs get their own origin ... Closes H-3 of the 2026-08-05 review, the last of its six highs. A plugin's interface was reverse-proxied onto the console's own origin and framed with `allow-same-origin`, so plugin JS ran as first-party code on that origin: one `fetch('/api/**', {credentials:'same-origin'})` and the BFF attached the operator's ADMIN bearer. That reached everything `plugin_may_access` withholds — arm pairing, read the host PIN, approve a device, read `/hooks`. The "open in new tab" link was the same escalation with no iframe involved at all. The fix is not a sandbox attribute, and it is worth writing down why, because the obvious change is the one that does not work. Dropping `allow-same-origin` gives the frame an OPAQUE origin; its subresource requests are then cross-site; the `SameSite=Lax` session cookie stops being sent; every plugin asset 302s to /login and the frame is blank. Nothing about the new-tab link is helped either. So the origin moves instead. A second listener on its own port (default PORT + 1) serves plugin UIs and nothing else: different ORIGIN — scheme+host+PORT — so the same-origin policy separates the plugin from the console: it cannot read the console's DOM, its cross-origin fetch of /api/** is unreadable (no CORS) and cannot mutate (Sec-Fetch-Site sees same-site). same SITE — cookie scope ignores the port and SameSite is computed on the site, so the session cookie still reaches the plugin listener and plugin pages keep working. Enforcement is two refusals and both are load-bearing: the console origin refuses /plugin-ui/**, and the plugin origin refuses everything ELSE — above all /api/**, which would otherwise hand the admin bearer right back to plugin JS that is now same-origin with that listener. Both are unconditional: if the plugin port cannot be bound, plugin UIs are DISABLED and the console says so, rather than falling back to the arrangement this exists to remove. Two consequences that would otherwise bite in the field: The port has to be open. Done for the Windows netsh rule, the firewalld service and the ufw profile. A browser stores a self-signed-certificate exception per ORIGIN, including the port — and a certificate interstitial can never be shown inside an iframe, so the frame would just sit blank with nothing on screen explaining why. A `no-cors` probe distinguishes it (a TLS failure rejects; any HTTP answer, even 401, resolves) and the console renders a card linking the operator to open the port once in a real tab. Also here: the health probe moved server-side to the console origin (it used to rely on being same-origin with the plugin), the postMessage listener now verifies `event.origin` — a real check rather than a tautology — and plugin-kit's `postMessage(..., "*")` is documented as load-bearing, since narrowing it to `location.origin` would now target the plugin's own origin and silently drop every message. Verified against a running console with a fake mgmt API and a fake plugin: console /plugin-ui/** → 404; plugin-origin /api/v1/hooks, /, /login, /_auth/logout → 404; plugin page loads 200 through its own origin; unauthenticated plugin origin → 401 (not a redirect to a /login it does not serve); a forged x-pf-listener header changes nothing on either listener; the plugin's own Clear-Site-Data / Access-Control-Allow-Origin / Set-Cookie are dropped by the proxy allowlist; the plugin origin's CSP names the console as its only frame-ancestors source; and with the port squatted, ui-config reports `unavailable`, the console still refuses /plugin-ui/**, and the console itself keeps working. Still wants on-glass confirmation in a real browser — the cookie and framing behaviour is reasoned from spec, not observed. cargo fmt --all --check clean; cargo check -p punktfunk-host --all-targets green on Windows; web console builds and typechecks.	2026-08-05 17:50:04 +02:00