[Feature] Plugin system: support embedded frontend UIs (iframe tab) + expose has_frontend in API

[custosonlinux]

Background

I've built a community plugin for PegaProx — https://github.com/custosonlinux/pegaprox-netapp-ontap — that
provides VM-consistent NetApp ONTAP snapshots, restore, clone, and SnapMirror® DR integration for NFS
datastores. The plugin has a full management UI served as a self-contained ui.html.

To make this work I currently maintain three local patches against PegaProx core that get overwritten every
time I run the built-in update. I'd like to upstream these changes so the plugin system can support any
plugin with a frontend UI — not just mine.

---

The three changes needed

1. Security headers — allow same-origin iframe embedding (2 lines)

pegaprox/app.py:

before:

response.headers['X-Frame-Options'] = 'DENY'

CSP: frame-ancestors 'none';

after:

response.headers['X-Frame-Options'] = 'SAMEORIGIN'

CSP: frame-ancestors 'self';

Plugin UIs are served under /api/plugins/{id}/api/ui — the same origin as the dashboard. DENY /
frame-ancestors 'none' prevents them from being embedded in an iframe at all. SAMEORIGIN / frame-ancestors
'self' restricts embedding to the same origin, which is the correct security posture.

---

2. Expose has_frontend and frontend_route in the plugin list API (2 lines)

pegaprox/api/plugins.py, in list_plugins():
'has_frontend': bool(plugin.get('has_frontend', False)),
'frontend_route': plugin.get('frontend_route', ''),

Plugins already declare these in their manifest.json. The API just needs to forward them to the frontend so
the dashboard can decide which plugins get a tab.

Example manifest.json:
{
"id": "netapp_ontap",
"has_frontend": true,
"frontend_route": "/api/plugins/netapp_ontap/api/ui"
}

---

3. Dynamic plugin tabs in dashboard.js — generic, not hardcoded

Currently I have a hardcoded netapp tab block in dashboard.js. The right solution is to make tab rendering
generic so any enabled plugin with has_frontend: true automatically gets a tab — no changes to core needed
when new plugins are installed.

Proposed approach:

In the tab definition array, replace the hardcoded netapp entry with a dynamic list from enabledPlugins:

// Replace the static tab list with plugins appended dynamically:
const pluginTabs = enabledPlugins
.filter(p => p.has_frontend)
.map(p => ({ id: plugin:${p.id}, label: p.name, icon: Icons.Package }));

In the tab content renderer, add a generic plugin iframe block:

{activeTab.startsWith('plugin:') && (() => {
const pluginId = activeTab.replace('plugin:', '');
const plugin = enabledPlugins.find(p => p.id === pluginId);
if (!plugin?.frontend_route) return null;
const theme = isCorporate
? (localStorage.getItem('corp-theme') === 'light' ? 'corp-light' : 'corp-dark')
: 'dark';
const src = ${plugin.frontend_route}?theme=${theme};
return (
<div style={{ margin: isCorporate ? '-8px -12px' : '0 0 -24px',
height: 'calc(100vh - 130px)' }}>
<iframe key={${selectedCluster?.id}-${src}}
src={src}
style={{ width:'100%', height:'100%', border:'none', display:'block' }}
title={plugin.name} />

);
})()}

This approach:

• Works for any plugin, not just NetApp
• Uses the frontend_route declared in the manifest as the iframe src
• Passes the current theme so plugins can style themselves accordingly
• Survives PegaProx updates without any re-patching

---

Why this matters for the update mechanism

With the built-in updater, every update to PegaProx currently wipes my three patches. A generic plugin
frontend system means plugin authors can ship a self-contained plugin directory and have it fully integrated
— including a UI tab — without touching core files.

---

Offer to contribute

I'm happy to submit a PR with all three changes if the approach sounds good to you. Changes 1 and 2 are
trivial. Change 3 requires building web/index.html from source, so coordination on that would be appreciated.

Plugin repo for reference: https://github.com/custosonlinux/pegaprox-netapp-ontap

Thank you an kind regards

Birger

[mkellermann97]

Hi @custosonlinux — thanks for writing this up so cleanly, and for building the ONTAP plugin in the first place. Plugin authors maintaining out-of-tree patches is a sign we left something the platform should provide, so this is genuinely useful feedback.

Reading through your three changes:

Changes 2 and 3 (expose has_frontend / frontend_route in the list-plugins API + dynamic tab rendering keyed off them) are clean additive surface-area work. Already-declared manifest fields just being forwarded, plus a small refactor of the dashboard's tab definition to enumerate over plugins instead of hardcoding. No security implication, low risk, exactly the right shape for a generic plugin-frontend hook. Confirmed in code: list_plugins() doesn't currently surface those fields, and the dashboard's tab list is indeed a static array. Both happily accepted via PR.

Change 1 (X-Frame-Options DENY → SAMEORIGIN, CSP frame-ancestors 'none' → 'self') needs more careful review on our end before we'd merge. Those headers were tightened deliberately during the recent security audit (M-class fixes, Apr/May 2026), and reopening even to same-origin is a posture call that I want @MrMasterbay to weigh in on. SAMEORIGIN is still considered secure against cross-origin clickjacking, so I expect it to land — but "the audit hardened this and now we're loosening it" is exactly the kind of decision that should not happen on a Marcus pass without architectural sign-off.

A PR with all three changes split into separate commits would be ideal — we could then merge 2+3 quickly and let Nico look at #1 separately. Alternatively if you'd prefer, the same effective result for ONTAP-only could be achieved by serving the plugin's UI on a separate /plugin-ui/<id> route that returns its own permissive CSP, leaving the main app frame-tight — but that's a workaround for your case, not a generic platform answer.

Worth flagging: there's been a quiet appetite for first-class plugin tabs for a while now (#286 Docker Swarm Manager from @alfonsokuen mentions the same gap) so what you're proposing benefits more than just ONTAP. Cross-linking those two so they land together in the planning bucket.

cc @MrMasterbay for the security-header call.

PegaProx is donation-funded — https://opencollective.com/pegaprox if you'd like to back the kind of work that lets the platform grow first-class plugin support.

— Marcus

[alfonsokuen]

@mkellermann97 thanks for the thoughtful review on @custosonlinux's PR. Cross-linking from #286 (Docker Swarm Manager).

Operational data point on the security-header call (change 1):

I've been running with frame-ancestors 'self' + X-Frame-Options: SAMEORIGIN in production for ~12 months on a 3-node Swarm cluster (~30 services across 3 tenants). The current implementation force-sets those headers via sed in a post-update patcher, exactly because the dashboard-embedded plugin UI cannot work without them. So in practice the looser posture is already deployed wherever Docker Swarm Manager is installed — formalising it via #381 just removes ~550 LOC of brittle patching that breaks on every PegaProx core refactor (the changelog 1.8.1 → 1.14.3 of alfonsokuen/pegaprox-docker-swarm is dominated by "upstream tweaked dashboard.js, sidebar disappeared, hotfix" cycles).

If @MrMasterbay would prefer the /plugin-ui/<id> standalone route instead, that also works for our case — Docker Swarm Manager is a full standalone UI, no nested-iframe contract.

To be ready for either outcome, I just shipped v1.15.0 of the plugin (commit df36e35) with:

• has_frontend: true + frontend_route: "ui" declared in manifest.json — matches the existing register_plugin_route(PLUGIN_ID, 'ui', ...) registration, zero API change.
• First automated test suite (107 tests, regex validators + env masking) + GH Actions CI on Py 3.10–3.12.
• Defence-in-depth fix to seven validator regexes ($ → \Z), caught by the new tests.

Happy to run as a second integration testbed once changes 2+3 land — the diff to delete patch_dashboard.py is essentially rm -rf once the upstream hook exists.

— Alfonso

[mkellermann97]

@alfonsokuen appreciate the operational data point — 12 months in production with the looser headers across a 30-service / 3-tenant Swarm footprint is a stronger validation than any pure threat-modelling exercise. Hard to argue with shipping data.

The v1.15.0 manifest layout you flagged (has_frontend: true + frontend_route: "ui") is aligned with what's being prepared upstream: the relative-form route maps to /api/plugins/<id>/api/ui server-side, which matches your existing register_plugin_route(PLUGIN_ID, 'ui', ...) registration. Zero manifest churn for you or @custosonlinux when it lands.

Will ping this thread and #286 when changes 2 and 3 are testable so you can run the integration testbed alongside the NetApp plugin. Change 1 (the headers) rides in the same release rather than going out piecemeal.

Nice catch on the $ → \Z regex anchor fix, by the way — that one bites people who haven't waded into the multiline-mode rules. Tests catching it on first introduction is the right pressure.

https://opencollective.com/pegaprox if the project keeps things flowing for you and your tenants.

— Marcus

[mkellermann97]

Shipped in v0.9.9.1, fully landed in v0.9.9.3 (the manifest correction). All three changes are in:

• Manifest fields — list_plugins() now exposes has_frontend and frontend_route from manifest.json
• Dynamic plugin tab — generic, keyed off has_frontend, no core changes per plugin
• Security headers — X-Frame-Options: SAMEORIGIN + CSP frame-ancestors 'self'

Server-side route validation does the heavy lifting on the security side: rejects external URLs, control characters, query/fragment injection, parent-segment traversal, and cross-plugin path hops. Manifest can declare relative form ('ui') or full path (/api/plugins/<id>/api/...) — anything else is dropped. Iframe sandbox attributes deny allow-top-navigation.

@custosonlinux — your NetApp ONTAP plugin should drop into the new tab with no manifest change beyond the has_frontend: true + frontend_route: "ui" you already declared. The register_plugin_route(PLUGIN_ID, 'ui', ...) registration matches.

@alfonsokuen — same for Docker Swarm Manager: v1.15.0's manifest layout already aligns. Happy to hear if the patch_dashboard.py deletion goes through cleanly when you run integration.

https://github.com/PegaProx/project-pegaprox/releases/tag/v0.9.9.3

Closing as the platform side is in. Re-open or open a follow-up if you hit edge cases.

https://opencollective.com/pegaprox

— Marcus