Fix canvas WebView2 surface auth via plugin-node cap URL#588
Closed
christineyan4 wants to merge 2 commits into
Closed
Fix canvas WebView2 surface auth via plugin-node cap URL#588christineyan4 wants to merge 2 commits into
christineyan4 wants to merge 2 commits into
Conversation
The Windows tray's Canvas WebView2 was hitting 401 when navigating to /__openclaw__/canvas/* paths because it built URLs against the gateway origin only, omitting the plugin-node capability token the gateway requires for cross-node plugin surface routes. The gateway already advertises a cap-scoped surface URL in its hello-ok response (pluginSurfaceUrls.canvas), e.g. http://<gateway>/__openclaw__/cap/<token> This change plumbs that URL through to CanvasWindow and uses it as the base for /__openclaw__/canvas/* rewrites, and as an additional trusted origin prefix in IsUrlSafe so a cap URL whose host doesn't match _trustedGatewayOrigin (e.g. 127.0.0.1 cap vs localhost origin) is not rejected by the safety check. Also clears the cached cap URL when a subsequent hello-ok/health update omits the canvas key, so a rotated/revoked token doesn't leave the node using a stale URL. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Codex review: needs real behavior proof before merge. Reviewed June 26, 2026, 11:57 AM ET / 15:57 UTC. Summary Reproducibility: yes. from source, not live: current main rewrites relative canvas routes to the effective gateway origin and does not read Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Keep the cap-scoped routing approach, but validate the advertised cap URL, propagate explicit removal through the client and any open CanvasWindow, include bridge-origin handling for validated cap URLs, add focused regression tests, and require redacted real WebView2 proof before merge. Do we have a high-confidence way to reproduce the issue? Yes from source, not live: current main rewrites relative canvas routes to the effective gateway origin and does not read Is this the best way to solve the issue? No for the current branch. The cap-scoped routing direction is plausible and narrow, but the implementation must validate the cap URL, fully clear revoked cap state, and keep cap-origin bridge behavior working before it is the best safe fix. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against e70868d82bf0. Label changesLabel justifications:
Evidence reviewedSecurity concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.
Problem
The Windows tray's Canvas WebView2 hits 401 Unauthorized when navigating to
/__openclaw__/canvas/*paths because it builds URLs against the gateway origin only, omitting the plugin-node capability token the gateway requires for cross-node plugin surface routes.Fix
The gateway already advertises a cap-scoped surface URL in its
hello-okresponse underpluginSurfaceUrls.canvas(e.g.http://<gateway>/__openclaw__/cap/<token>). This PR plumbs that URL through toCanvasWindowand uses it as the base for/__openclaw__/canvas/*rewrites.Additionally:
IsUrlSafeso a cap URL whose host doesn't match_trustedGatewayOrigin(e.g.127.0.0.1cap vslocalhostorigin) isn't rejected by the safety check.hello-ok/healthupdate omits the canvas key, so a rotated/revoked token doesn't leave the node using a stale URL.Files changed
src/OpenClaw.Shared/Models.cspluginSurfaceUrls.canvasfromhello-oksrc/OpenClaw.Shared/WindowsNodeClient.csCanvasSurfaceUrl; clear when canvas key absentsrc/OpenClaw.Tray.WinUI/Services/NodeService.csCanvasWindowon connect + on updatesrc/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs/__openclaw__/canvas/*via cap base; trust asIsUrlSafeprefixNet: +128 / -14 across 4 files. No new files, no API changes outside the tray.
Testing
net10.0-windows10.0.22621.0 / win-arm64(0 warnings, 0 errors)canvas.presentwith/__openclaw__/canvas/generative-art.htmlnow renders the real content instead of the dashboard SPA shell / 401 page.Known limitations (deferred)
canvas.presentand the dispatcher-enqueuedSetTrustedGatewayOrigin— theoretical, never observed.https://gw/__openclaw__/canvas/*) still go through the gateway origin path; gateway doesn't currently emit those.