Route client-side RA cloud requests through router /cloud proxy on local builds (CORS fix)

[AustinChangLinksys]

Problem

When the PrivacyGUI web app is served from the router itself (local build), the browser origin is the router's LAN IP. Client-side Remote Assistance (RA) requests that hit the cloud host directly are blocked by CORS. This is a confirmed, current-production problem.

1.x solved this by injecting a getHost closure into LinksysHttpClient (via the removed cloudRepositoryProvider) so client requests went through the router's /cloud/ reverse proxy (same-origin). That path is dead in 2.x: LinksysHttpClient.getHost / combineUrl still exist but combineUrl is never called, and every caller builds an absolute cloud URL itself, bypassing getHost.

Scope

RA only. Client-side RA requests proxy through the router on local builds; CA-side requests always go direct to cloud (the CA portal is cloud-hosted — proxying would misroute it). Firmware OTA and geolocation are explicitly out of scope.

Proposed solution

Add a small, testable host-resolution layer instead of restoring the dead getHost path:

• kProxyPrefix constant (/cloud) — single point of change once FW confirms the prefix.
• CloudHostResolver — decides the URL base to prepend to a Guardian endpoint:
  • CA-side → always direct cloud base.
  • Client-side → router proxy base (<origin>/cloud) iff local build AND origin resolvable; otherwise direct cloud (safe fallback).
• Inject the resolver into GuardianApiClient and thread forCA through _buildUrl / _request, derived from sessionToken != null so it stays in lock-step with the auth-header branch (no drift possible).
• Host source = Uri.base.origin (scheme + host + port). Chosen over window.location.host because same-origin/CORS requires the scheme to match; Uri.base.origin preserves it and is already an established pattern in this repo.

Acceptance Criteria

• On a local build (BuildConfig.isLocal() == true), client-side RA requests (fetchDeviceToken, getSessions, getSessionInfo, createPin, deleteSession) target <Uri.base.origin>/cloud/v1/guardians/....
• CA-side requests (getSessionInfoForCA, deleteSessionForCA) always target the cloud host directly, even on a local build.
• On a non-local build, every RA request (client + CA) targets the cloud host directly — behavior byte-for-byte identical to today.
• When the origin is unresolvable (empty), client-side requests fall back to the cloud host rather than failing.
• Uri.base.origin scheme is preserved (http stays http, port preserved) — no forced https://.
• The proxy path prefix is a single configurable constant (kProxyPrefix); changing the FW prefix requires no other code change.
• Existing RA flows (dialog, banner, CA confirm view) work unchanged; remote_assistance_service_test.dart stays green.

Blocked / open items

• FW proxy prefix unconfirmed — kProxyPrefix is one constant; flip the value when FW lands. This blocks on-device sign-off, not implementation. (label: need-fw-confirm)
• E2E mock builds are local (isLocal() == true) → client RA calls take the proxy path; if the E2E harness mocks Guardian at the network boundary, confirm it intercepts /cloud/... URLs too.

Tests

• test/core/cloud/cloud_host_resolver_test.dart — resolver logic (7 cases: local+client, local+CA, empty-origin fallback, non-local, port preserved, http scheme preserved, default constructor).
• test/core/cloud/guardian_api_client_test.dart — URL assembly (client methods → proxy URL incl. session-id substitution; CA methods → cloud URL under the same resolver).
• test/core/cloud/services/remote_assistance_service_test.dart — regression, stays green unchanged.

[AustinChangLinksys]

FW-side verification (live router test, 2026-07-28)

Tested end-to-end against a router running the updated FW with the /cloud proxy (M60TB, lighttpd 1.4.75 + stunnel). The app side is correct — client-side RA requests hit <origin>/cloud/v1/guardians/... as designed, and a local nginx pass-through to the router HTTPS works. The remaining blockers are entirely in the router FW. All router/nginx changes below were reverted after testing; this is a diagnosis, not a merged fix.

Ground-truth matrix (tested directly against the cloud endpoint)

Host header	Path	Result
qa.cloud1.linksyssmartwifi.com	/cloud/v1/guardians/devices/tokens	✅ 200, real token (55 bytes)
qa.guardian.tools	/cloud/v1/guardians/devices/tokens	❌ 404
qa.guardian.tools	/v1/guardians/devices/tokens (prefix stripped)	✅ 200, real token (55 bytes)

→ Host and prefix are coupled: guardian.tools requires the /cloud prefix to be stripped; cloud1 accepts the /cloud prefix as-is.

Blocker 1 — SPA fallback swallows /cloud (must fix; this is the "redirected to index" symptom)

/etc/lighttpd/conf.d/40-static.conf (line 62):

$HTTP["url"] !~ "^/(api/|cgi-bin/|usp-test/|usp-ws)" {   # exception list is missing cloud/
    url.rewrite-once = ( ... "^/(.*)$" => "/index.html" )  # /cloud/v1/... gets rewritten to /index.html
}

url.rewrite-once runs before mod_proxy, so /cloud/v1/... is rewritten to /index.html before the proxy rule (30-proxy.conf, "/cloud" => stunnel:8082) can match → the request never proxies and the router serves its own index.html.

Fix: add cloud/ to the exception regex → "^/(api/|cloud/|cgi-bin/|usp-test/|usp-ws)". Verified live: after this change the proxy fires (response origin switches from the router's index to CloudFront).

Blocker 2 — Host / prefix mismatch (surfaces only after Blocker 1 is fixed)

30-proxy.conf rewrites the upstream Host to guardian.tools via map-host-request (which requires the prefix stripped), but:

• stunnel actually connects to qa.cloud1.linksyssmartwifi.com:443 (stunnel.cloud.connect)
• lighttpd mod_proxy does not strip the /cloud prefix — it forwards the full URI

The resulting combination sent to the cloud is Host: guardian.tools + /cloud/v1/... = the 404 row above. FW must make the combination self-consistent, one of:

• (A) Drop/adjust map-host-request so the Host stays cloud1 (cloud1 accepts the /cloud prefix). Minimal change — but the stunnel SNI/cert must be aligned; when I tried forcing Host→cloud1, a SNI/cert mismatch produced a CloudFront 403, so SNI needs handling too.
• (B) Keep Host = guardian.tools and strip /cloud before proxying (e.g. url.rewrite ^/cloud/(.*) → /$1).

Note: stunnel [cloud] connect = qa.cloud1... initially looked wrong, but cloud1 returns a real token for /cloud/v1/... directly, so the target is correct and does not need changing. The actual inconsistency is lighttpd's host rewrite vs. the non-stripped prefix.

App-side status

No app change needed. kProxyPrefix = /cloud matches the FW proxy location. Once FW resolves Blockers 1 & 2, on-device sign-off can proceed and this issue's need-fw-confirm can be cleared.

[AustinChangLinksys]

Local E2E findings — client-side RA /cloud/ proxy is blocked on the FW side (Host/prefix mismatch)

Summary: App-side code is correct — client RA requests now go same-origin to <origin>/cloud/v1/guardians/.... The remaining blocker is on the router: lighttpd forwards to the guardian.tools origin while keeping the /cloud prefix, and that specific combination is the only one that returns the SPA index.html instead of the real API. FW needs to make the Host and the prefix consistent.

Ground-truth matrix (curl directly against QA cloud, reproducing what the router sends)

#	Host + path sent upstream	Result	Meaning
1	Host: qa.guardian.tools + keep /cloud/v1/...	200 text/html (SPA index.html)	❌ What the router sends today → SPA, no token
2	Host: qa.guardian.tools + strip /cloud → /v1/...	200 application/json	✅ Hits the real API
3	Host: qa.cloud1.linksyssmartwifi.com + keep /cloud/v1/...	200 application/json	✅ Hits the real API

In cases 2 & 3 the JSON is {"code":"MISSING_PARAMETER","errorMessage":"Client type is missing"} — expected, because bare curl omits the client-type header. The app sends it, so it will receive a real token. The point is cases 2 & 3 reach the real API (JSON), while case 1 returns the SPA (HTML).

Root cause: Host and prefix are coupled. The router's current combo (case 1: Host: guardian.tools + kept /cloud) is the only combination that returns the SPA. Making them consistent unblocks it.

Fix on FW — pick one (both verified to reach the real API)

• Option A — strip the prefix: keep map-host-request → qa.guardian.tools, have mod_proxy strip /cloud so it forwards /v1/... (→ case 2).
• Option B — align the Host: keep the /cloud prefix, change map-host-request from guardian.tools to qa.cloud1.linksyssmartwifi.com (stunnel already connects to cloud1, so this is the more self-consistent choice) (→ case 3).

Already resolved on FW ✅

The SPA fallback in 40-static.conf used to rewrite /cloud/... → /index.html before mod_proxy could match; /cloud/ is now in the rewrite exception list, so the proxy fires correctly. The only remaining item is the Host/prefix pairing above.

How to reproduce / verify

A. Reproduce the current failure (what the router sends today — case 1):

Q='serialNumber=<SN>&macAddress=<MAC-urlencoded>&uuid=<UUID>'

# Hit the router directly over https, bypassing the local dev proxy:
curl -sk -o /dev/null -w "http=%{http_code} ctype=%{content_type}\n" \
  "https://<router-lan-ip>/cloud/v1/guardians/devices/tokens?$Q" \
  -H 'Accept: application/json'
# Broken -> http=200 ctype=text/html   (SPA index.html)
# Fixed  -> http=200 ctype=application/json

B. Confirm the upstream expectation (which Host/prefix combo the API accepts):

# Case 2 - strip /cloud (Option A target):
curl -sk "https://qa.guardian.tools/v1/guardians/devices/tokens?$Q" -H 'Accept: application/json'

# Case 3 - keep /cloud, Host=cloud1 (Option B target):
curl -sk "https://qa.cloud1.linksyssmartwifi.com/cloud/v1/guardians/devices/tokens?$Q" -H 'Accept: application/json'

# Both return application/json (the real API).

To get a real token instead of MISSING_PARAMETER, add the app's client-type header:
-H '<client-type-header>: <client-type-id>' (see kHeaderClientTypeId / kClientTypeId in lib/constants/cloud_const.dart).

C. End-to-end acceptance (after the FW fix lands):

1. Build local web (force=local), open it from the router-hosted GUI (origin = router LAN IP).
2. Open the Remote Assistance dialog.
3. DevTools -> Network, the client RA request should be:
   • Request URL: https://<router-lan-ip>/cloud/v1/guardians/devices/tokens?... (same-origin, no CORS error)
   • Response: 200 application/json carrying linksysToken (not SPA HTML)
4. CA-side flow must still hit the cloud host directly (unchanged).

Pass criteria: case A returns application/json, and the RA dialog obtains a token with no Failed to fetch / CORS error.