A custom plugin page often needs two different kinds of data:
- Live and small: current values, commands. The WebSocket channel handles this perfectly.
- Bulk and persisted: a larger accumulated dataset (history, stats, a report model the page renders). There's no good way to deliver this privately today.
- Put it under www/ gives you cheap and gzipped, but static files are served before login (so the login page itself can load), so the data is readable by anyone who can reach the port. Not OK for anything privacy-relevant, since heat-pump runtime/COP patterns are basically an occupancy fingerprint.
- Push it over the WebSocket uses a channel designed for small live messages; serializing a big payload on the plugin's worker thread per delivery doesn't really scale as a bulk transport.
- Reverse-proxy auth works, but it's a per-deployment step a plugin can't rely on when shipping to many users.
The idea: what if Domoticz had an authenticated static location, say files under www/protected/, served exactly like other static files (gzip, caching, on the web-server thread) but only to a logged-in session? A plugin writes its per-instance JSON there; a logged-in browser fetches it with its existing session cookie; an anonymous request gets a 401. It reuses the static serving and session handling that already exist, keeps the work off the single plugin worker thread (nice on a Pi), and would help any plugin that needs to hand its custom page some private data, not just mine.
In other words: the WebSocket channel gives custom pages a live/command channel; this would give those same pages an authenticated way to pull their bulk state. Two halves of one story.
Does this fit how you see the custom-page side evolving? If there's interest I'm happy to work up the details and a patch sketch. Curious what others building custom pages think.