Web Administrator

Web Administrator

Since v1.1.2 the plugin ships a web UI module for the OIE Web Administrator. If your users manage the server from a browser instead of the Swing Administrator, they get the same role enforcement and the same role-management UI there. No separate install, the module is part of the plugin zip:

rbac-1.1.2.zip
└── rbac/
    ├── rbac-*.jar, plugin.xml, sqlmap.xml
    └── webadmin/
        ├── plugin.json
        └── web/plugin.js

The web administrator discovers the module at <extensions>/rbac/webadmin/plugin.json and loads it after login.

Task Gating in the Browser

At browser login the module fetches the user's granted permissions and installs an authorization controller into the web host. From then on the web UI applies the same task gating as the Swing client:

• Navigation items - views the role does not grant (Users, Events, Extensions, and so on) disappear from the nav.
• Task buttons - task-pane actions like Deploy Channel or Delete Channel are hidden unless the role holds the mapped permission.
• Context menus - right-click entries follow the same rules as the task pane; a read-only role keeps Refresh and Export Channel but loses Deploy and Delete.
• Settings tabs - the Settings nav itself is always shown, matching Swing; individual tabs are gated by their group-specific permissions (Server Settings, Tags, Configuration Map, Database Tasks, Resources).

The rules are the Swing controller's, ported 1:1. A mapped task is shown only if the user's permission set contains the mapped permission. An unmapped task is allowed through, because the server enforces the real check on every call.

This gating also reaches further than the Swing client can. Swing only routes task-pane items through the authorization hook and cannot hide buttons built into a panel body, an engine limitation that applies to every plugin (see Security Model). The web host's panels consult the controller directly, so in-panel controls like Add, Edit, Delete, and Assign Role hide when the role does not grant them.

The Roles Tab

Users holding View Roles get a Role-Based Access Control settings tab with the same management UI as Swing: a roles table over a user-assignments table, with Add, Edit, Delete, Assign Role, and Remove Role. Users without the permission never see the tab.

Behavior matches the Swing panel:

• Same gating - Refresh needs View Roles; the Add/Edit/Delete and Assign/Remove buttons need Manage Roles.
• Same immediate commits - each action is applied to the server the moment its dialog confirms; the tab does not stage changes behind a Save button, and says so in the notice above the tables.
• Same confirmations - delete and remove confirmations, the assignment impact preview (channel scope plus the full permission list before you assign), and the admin-role delete guard all use the same dialog texts as Swing, verbatim.
• Same partial view - a user with View Roles but not manageUsers still sees the roles table; the assignments area degrades to a hint because listing users requires manageUsers.

Role Editor Parity

The Add/Edit Role dialog is a port of the Swing role editor, not a reimagining:

• Same permission groups - the same 14 ordered groups (Channels, Messages, Dashboard, ...), with uncategorized extension permissions bucketed under their publishing plugin and anything left in a trailing Other group.
• Same presets - Select All, Deselect All, and the Read-Only preset that checks all view permissions.
• Same warnings - the Manage Extensions blast-radius tooltip, the missing-base-permissions warning, and the guard when a channel-restricted role is about to flip back to all-channels access.
• Same channel restrictions - All Channels or Specific Channels, with deleted-channel references listed separately and kept unless you explicitly purge them.
• Same admin-role locking - the admin role's name, permissions, and channel controls are locked; only the description is editable.

Fail-Closed

If the permission fetch fails at login, the controller still installs and denies every task. The Roles tab is skipped too, since a dead tab is worse than no tab. A throttled reload retries in the background, at most once per 15 seconds, and when a retry succeeds the nav and task panes re-render against the recovered permission set.

Either way, hiding is a courtesy for the user, not the security boundary. Every REST operation is checked by the server-side authorization controller regardless of what the browser shows.

Kept in Lockstep with Swing

The web task-permission map is a hand-maintained 1:1 port of the Swing client's, and a checked-in JSON parity artifact (webadmin/web/task-permission-map.json) keeps the two from drifting: a unit test asserts the web map equals the artifact exactly, values and key order, and the Swing map documents the same file as its parity reference. When a mapping changes, all three change together.

If Nobody Uses the Web Administrator

The module is two static files served to browsers. Nothing runs on the server, and Swing clients never load it. On a server where nobody logs into the Web Administrator it is inert.