[jherforth]

Draft: don't merge yet. The release order is still being decided (1.10 first, or with this).

Fixes mrramam#50, #49 and the CORS part of #62. Until now, a plugin could do anything the Admin Panel can:

• write settings, the proxy whitelist included;
• export the database and its encryption key when no PIN is set;
• stage a restore and restart the server;
• use another plugin's storage, notifications or Home Assistant panel by naming its id.

That was possible because plugin frames were sandboxed with allow-same-origin and served from HomeGlow's own origin, and the API allowed any origin.

What changes

• Opaque sandbox.

  • Plugin frames (and the Admin preview) drop allow-same-origin. A plugin can't reach the dashboard's DOM or storage, or read another plugin's page.
  • The dashboard posts to frames with "*", and accepts their messages from origin "null", still only from its own frame.

• A token per page.

  • /widgets/:filename injects a frozen __HOMEGLOW_PLUGIN__, plus a frame script (server/utils/pluginFrameShims.js).
  • The script carries an HMAC token for plugin:<id>, or widget:<filename> for a plain widget. It's signed with a new PLUGIN_TOKEN_SECRET setting, which is made on first use and never returned.
  • The script adds the token to fetch and XHR calls to HomeGlow's own host, and to nothing else. Plugins and the SDK need no change.

• One request policy (server/utils/pluginRequestPolicy.js). A request with Origin: null needs a valid token, and reaches only:

  • its own /api/plugin/v1/{storage,settings,ha,notify}/<id> routes;
  • the core reads in the plugin guide (§10.2), plus its four household writes: clams in and out, a chore done or undone;
  • the proxy;
  • theme files, with no token, because FontFace can't add one.

  Everything else answers 403 with a reason. /api/calendar-sources leaves out url and username for plugins, since a private ICS link is a secret.

• CORS.

  • @fastify/cors now answers per request instead of *: a plugin's allowed requests, the dev server, and a new CORS_ORIGINS list.
  • The proxy and the event stream no longer set * by hand.

• localStorage throws in an opaque origin, so the frame script puts a stand-in in its place, per plugin and per display.

  • It's seeded through the frame's name and kept by the dashboard (client/src/utils/pluginLocalStore.js).
  • The published plugins' old keys are carried over once per display, for the plugins installed at that moment.
  • The original keys stay where they were, for a rollback.

Compatibility

• Published plugins need no change to keep working. All ten I ran work as they are, with their saved data carried over.
• NewsTicker used to add its own feed hosts to the whitelist. From its code, the old version's Allow it button would now fail and show "Could not update the proxy whitelist". I didn't run that. NewsTicker 1.0.1: stop writing the proxy whitelist itself HomeGlowPlugins#60 (1.0.1) replaces that with a pointer to System → Connections, and works on older HomeGlow too.
• Third-party plugins:
  • a call to a core route outside the list now gets 403;
  • localStorage keys saved before the upgrade aren't carried over, only the published plugins' are.

Testing

• Server npm test:
  • the full suite passed except one theme test, which asserted the old global *. That test is updated and passes, and asks as a plugin frame does.
  • new pluginRequestPolicy.test.js: tokens, routes, preflights, public files, origins.
  • new pluginIsolation.test.js, on a real server with requests sent as a sandboxed frame sends them:
    • no or forged token: refused;
    • another plugin's storage, settings, notify and Home Assistant routes: refused;
    • core reads: open, with the calendar address stripped;
    • settings, backup, restart, PIN, install, stream and widget-page requests: refused;
    • preflights answered only where allowed;
    • foreign origins get no CORS headers;
    • no-Origin requests unchanged.
• Client: vitest (749, including new pluginLocalStore.test.js), check:i18n and build all pass.
• Edge, with ten published plugins plus a probe plugin on one display: 32 of 32 checks pass.
  • All ten plugins render: GuestWifi, Grill, Polls, CalendarAgenda, Chore Metrics, DateClock, Countdown, Messages, WeatherGlance, NewsTicker.
  • Every escape the probe tried was refused: the parent page, the dashboard's storage, settings writes, backup export, another plugin's page and storage, and renaming itself.
  • Core reads, its own storage, localStorage (by method and by property), theme files, the theme message and a declared event all work.
  • GuestWifi showed a network saved before the upgrade, and Grill got only its own key.
  • localStorage persists across a reload.
• A Home Assistant panel against the fake Home Assistant: it read a switch's state and toggled it through the token path.
• Not tested:
  • a real install with real data;
  • touch swipe, expand and celebrate (they share the message check the tests cover);
  • production's same-origin setup in a browser. The Edge runs used the Vite dev server, where the dashboard and API are on different ports.

🤖 Generated with Claude Code

[mrramam]

I checked this against a bunch of plugin's API calls, plus the plugins we run in production.

• Routines breaks. It creates, edits, hides and deletes chores and schedules: POST /api/chores, PATCH and DELETE /api/chores/:id, and POST, PATCH and DELETE /api/chore-schedules/:id. PLUGIN_POSTS only has complete, uncomplete and the clams routes, so setting up or changing a routine gets a 403. It isn't one of the ten you ran. The other published plugins only call routes in READ_ROUTES and PLUGIN_POSTS, apart from NewsTicker's settings write, which HomeGlowPlugins#60 handles.
• CSRF: agree with leaving it to README calls the Admin PIN access control; the PIN is an unsalted SHA-256 and the API allows any origin mrramam/HomeGlow#62. The multipart uploads are the sharpest case: /api/widgets/upload, /api/themes/upload and the photo, sound and background uploads.
• Smaller: a no-cors GET from a plugin frame carries no Origin, so the policy never sees it. The plugin can't read the answer, so this only matters for a GET that changes state. I haven't checked which GET routes do.

It merges cleanly onto my production build, with #319 too.

[jherforth]

-Routine is built in so it would only break if someone reinstalls it and I think we can consider the plugin deprecated.
-Cross site can be addressed in your mrramam#62 issue.
-I checked every GET route the server has, and none changes anything that matters. The Google sign-in callback needs a code the server issued itself. One small nuisance: ?refresh=1 on the store listing and the weather skips their caches. A plugin could repeat it to use up GitHub's hourly limit or the weather key's daily quota. It harms nothing on the network, so I'd add it to the follow-ups.

I'm going to push 1.10 and this will not be merged in that release, this will go in 1.11 and can be merged to main once 1.10 goes live.