Repository navigation
Refuse wasip2 class extenders at the integration proxy, and say why (#1700, piece 5) - #1831
michielbdejong wants to merge 2 commits into
Conversation
…1700) Answer 5 on #1700: wasip2 class extenders do not reach the proxy. They were already refused, because a class extender's identity is its plugin agent in PluginMeta and the host has no installation agent to sign as for it, but the error depended on which later check tripped: the missing `proxy` platform, or "no app agent on this node". `HostCore::fetch` now refuses a class extender's request to the proxy first, by `atomic-proxy:` or by the proxy's absolute URL, even when the manifest lists the proxy origin, with CLASS_EXTENDER_PROXY_REFUSAL, which says the proxy only accepts an installation's node agent and points at JS plugins. Documented under "Class extenders and the integration proxy" in docs/src/plugins/creating-plugins.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Merge-risk triage (2026-09-28). This is a read-only review of this PR's own diff. The rule it applies: nothing that works today may break for existing users or clients, and new behaviour is added alongside the old. The stack is being rebased onto Verdict: SAFE Adds an earlier, clearer refusal for class extenders calling the proxy; those requests already failed in 🤖 Generated with Claude Code |
|
Closing as part of the plugin-host stack cleanup (Q-101): not needed by atomic-plugins now. See the inventory at #1726 (comment). The branch is kept, and pin candidates are unaffected. Closed by Claude (VPS coordinator) on behalf of Michiel. |
Piece 5 of #1700 (answer 5): wasip2 class extenders don't reach the integration proxy.
First of three stacked PRs:
claude/atomic-proxy-scheme(atomic-proxy: URLs for plugins, resolved to the delegated connection on the configured proxy (#1700, answer 4) #1725);The three pieces don't depend on each other. They're stacked only so each diff stays small.
What changes
wasip2 class extenders were already refused at the proxy: their identity is the plugin agent in
PluginMeta, so the host has no installation agent to sign as. But the error you got depended on which later check tripped first: an undeclaredproxyplatform, or "no app agent on this node".HostCore::fetchnow refuses a class extender's proxy request before any other check, withCLASS_EXTENDER_PROXY_REFUSAL. It covers bothatomic-proxy:URLs and the proxy's absolute URL, even when the manifest lists the proxy origin innetwork.origins. The message says the proxy only accepts an installation's agent on this node, and points to JS plugins instead.docs/src/plugins/creating-plugins.md, and theproxybullet links to it.Tests
host_core::tests::a_class_extender_is_refused_at_the_proxy_and_told_whysets up a class-extender host whose manifest declares the proxy origin, on a node with a proxy configured. It checks that both URL forms are refused with exactly that message, before any connection is made.cargo test -p atomic-server --liband clippy-D warningspass, and so did the pre-commit hook's workspace clippy.🤖 Generated with Claude Code