fix(v3/assetserver): give webview requests a loopback RemoteAddr

[midagedev]

What

The asset server synthesizes an http.Request for every webview request and,
when the platform gives no peer address, fills RemoteAddr with the RFC 5737
TEST-NET placeholder 192.0.2.1:1234. A webview request originates from the
embedded webview on the local machine, so this makes the most local possible
caller look like a routable remote peer. This changes it to a loopback address,
127.0.0.1:0.

// v3/internal/assetserver/assetserver_webview.go
if req.RemoteAddr == "" {
    req.RemoteAddr = "127.0.0.1:0" // was: "192.0.2.1:1234"
}

Why it matters

Nothing in the Wails tree reads RemoteAddr — the only assignment is this one
line, and no production code compares or parses it (verified by grepping the
whole v3/ tree). So this changes no Wails-internal behaviour. The impact is on
a user Handler wired into the asset server that gates on request origin — the
standard "only accept loopback callers" check:

ip := net.ParseIP(host); ip != nil && ip.IsLoopback()

Today such a handler rejects the webview, because 192.0.2.1 is not loopback.

Wails' own code already treats that exact address as the canonical non-loopback
peer. v3/internal/commands/mcp.go gates MCP requests with
mcpHostIsLoopback (net.ParseIP(host).IsLoopback()), and its test pins the
classification:

// v3/internal/commands/mcp_test.go:111
{name: "non-loopback host", host: "192.0.2.1:1234", origin: "http://192.0.2.1:1234", want: false},

So a Wails app that reuses Wails' own loopback-gating pattern in front of its
asset server would reject its own webview. The synthesized address should agree
with how the framework classifies addresses elsewhere: a webview is loopback.

Sibling precedent

127.0.0.1 is what Wails already uses as its canonical loopback in the same MCP
gate's tests (mcp_test.go:108, want: true). This change makes the
asset-server placeholder consistent with that.

Test

Added TestWebViewRequestPeerIsLoopback in
v3/internal/assetserver/assetserver_webview_test.go, reusing the existing
contextWebViewRequest / contextWebViewResponse fakes. It drives
processWebViewRequest and asserts the handler observes a loopback
RemoteAddr.

FAIL-first checked: with the old 192.0.2.1:1234, the test fails with
RemoteAddr = "192.0.2.1:1234", want a loopback peer; with the fix it passes.
go test ./internal/assetserver/, go vet, and gofmt -l are clean.

Scope / provenance

• One fix, one added test, one changelog entry (v3/UNRELEASED_CHANGELOG.md).
• Original work; MIT, same as the project. No third-party code.
• I read this as a bug fix to an undocumented internal placeholder rather than a
  public-API change — RemoteAddr was never a documented contract and stays a
  non-routable synthetic address either way. If maintainers consider the
  observable value part of public behaviour and would prefer a WEP, I'm happy to
  open one.

Summary by CodeRabbit

• Bug Fixes

  • WebView requests now appear to originate from the local device, allowing origin-based request handlers to process them correctly.
  • Improved compatibility for handlers that restrict access based on the request’s remote address.

• Documentation

  • Added a changelog entry describing the updated WebView request origin behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a038b9f7-a1b5-4ec6-964e-a712174df56c

📥 Commits

Reviewing files that changed from the base of the PR and between 9215c89 and e8b76a4.

📒 Files selected for processing (3)

• v3/UNRELEASED_CHANGELOG.md
• v3/internal/assetserver/assetserver_webview.go
• v3/internal/assetserver/assetserver_webview_test.go

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

Walkthrough

WebView requests without a RemoteAddr now receive 127.0.0.1:0. A new test verifies the peer address as loopback. The changelog documents the behavior.

Changes

WebView loopback peer address

Layer / File(s)	Summary
Synthesize and verify loopback RemoteAddr v3/internal/assetserver/assetserver_webview.go, v3/internal/assetserver/assetserver_webview_test.go, v3/UNRELEASED_CHANGELOG.md	WebView requests now use 127.0.0.1:0 instead of the TEST-NET placeholder. The test verifies that handlers receive a loopback peer address. The changelog records the fix.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: 🔵 Low · up to e8b76

WebView requests without a peer address will now appear to come from loopback, which may cause application handlers that use loopback as an authorization signal to allow requests they previously rejected. The change is mergeable with explicit owner awareness that this synthetic address should not independently prove caller identity.

Suggested reviewers: taliesin-ai, leaanthony

Poem

A rabbit checked the address bright,
“Loopback hops are just right!”
The handler waved from near,
While tests made things clear,
And the changelog tucked in the light.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely identifies the asset-server fix and the loopback RemoteAddr behavior.
Description check	✅ Passed	The description clearly explains the change, motivation, scope, implementation, and validation. It provides sufficient context for review and identifies the added test and executed checks.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}