Add WASM module registry and admin panel extensibility via manifest convention#253
Open
zyrakq wants to merge 1 commit into
Open
Add WASM module registry and admin panel extensibility via manifest convention#253zyrakq wants to merge 1 commit into
zyrakq wants to merge 1 commit into
Conversation
Made loaded WASM modules visible to administrators Allowed modules to present a branded identity in the dashboard Enabled modules to surface their own configuration UI in admin Equipped module authors with built-in admin access control Turn WASM into a first-class extension model for the admin Remove the need for a separate admin interface per extension Spare module authors from re-implementing admin access control
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the extensibility described in #252.
What this adds:
GET /_/admin/wasm-modules— new API endpoint listing all loaded modules with their metadata/wasm-modules— shows each module with icon, display name, and description/_/wasm/<file-stem>/manifestwith a JSON object:display_name,icon,description,config_path. The path segment must match the file-stem of the.wasmfile; a mismatch means the manifest is silently ignored. This makes the contract opt-in and collision-free/wasm-modules/:name— when a module declares aconfig_path, the admin fetches it with admin credentials and injects the returned HTML fragment. Script tags are re-cloned so module JS initializes correctlyis_admincheck added towasm-runtime-guest— since this feature opens the door to admin-panel extensions, module endpoints that serve management UI must be able to guard access. The project didn't previously need this in the guest crate, but shipping admin-facing modules without a built-in auth check would push that burden onto every extension author individuallyStyle isolation:
The settings fragment is injected directly into the admin page DOM, so TrailBase's own styles will bleed into it. Extension authors should wrap their settings UI in a Web Component using Shadow DOM to get full style isolation. This is the recommended approach for any
config_pathimplementation.Real-world example:
To verify the manifest convention end-to-end, wcauth-tb-component can be used as a test module — it already implements the manifest endpoint and exposes a settings page. Build it from source, place the resulting binary as wcauth.wasm in traildepot, and it should appear in the WASM Modules page with its manifest applied.
Compatibility:
Non-breaking. Modules without a manifest endpoint continue to work exactly as before and appear in the list using their file-stem as the display name.