fix(ios): route editor REST requests through a native relay under Lockdown Mode

[dcalhoun]

What?

Under iOS Lockdown Mode the editor's REST traffic fails — every request comes back as "Could not get a valid response from the server." This routes that traffic through a native loopback relay so it works.

Supersedes #544 and #610: the same work as a single branch against trunk, plus the fixes from an adversarial review of the combined diff. Both are left open for now.

Why?

With Lockdown Mode on, nothing in the editor that talks to the site works — media uploads, link search, embeds, and saving all fail with api-fetch's generic error. Where the request stops depends on its shape: every api-fetch request carries Authorization, so it is preflighted and the browser abandons it after the OPTIONS response fails the origin check — it never reaches the site. A request needing no preflight does reach the site and is processed, and only its response is discarded.

The editor is a file:// page whose cross-origin requests normally bypass CORS through allowUniversalAccessFromFileURLs. Lockdown Mode stops honoring that exemption while the page still sends Origin: file://, and WordPress sanitizes that value through a protocol allowlist that excludes file — so it answers with an empty Access-Control-Allow-Origin and WebKit rejects the response. Ref CMM-2014.

How?

The web view fetches http://127.0.0.1:<port>/proxy/<path> on the media upload server from #357, and native code performs the real request with the configured credential, answering with CORS headers we control.

The caller supplies a path, not a URL. Everything after /proxy/ resolves natively against the configured site API root, so the relay cannot be pointed at another host by construction. Dot segments are refused, including the percent-encoded separators a server may decode before it normalizes. Redirects out of the root are refused rather than followed, except one that differs only by an http→https upgrade. Any client-supplied Authorization is discarded in favor of the natively held one. Which route within the site is reached remains the caller's: the query is forwarded as-is, and WordPress prefers a rest_route parameter in it over the path — no wider than what the editor may request through the relay directly.

The relay is the transport, not an api-fetch middleware. apiFetch.use() can never run innermost, so a middleware would short-circuit past api-fetch's own request building and response parsing. Wrapping fetch puts the relay below all of it, changing only where the request goes.

Only the configured site is relayed. A target matches when its host is the configured host under a www. or loopback spelling and its port is identical. Only the scheme may differ, so a site whose siteurl is http behind a TLS-terminating proxy still relays. Anything else keeps the direct path it had before a relay existed — as does any no-cors request, whose response is opaque, so there is no CORS rejection to solve and a browser would strip the relay's bearer token from it anyway.

Preflights are told apart from deliberate OPTIONS by Access-Control-Request-Method, in the HTTP server and in the wp-env CORS shim, which had the same bug: canUser reads Allow off an OPTIONS response, and answering it with a blanket 204 reported that the user could do nothing, with no error surfaced.

Three gaps are deliberate:

• jQuery.ajax / wp.ajax (XHR) still go direct and still fail under Lockdown Mode. Nothing in the editor's own REST path uses them today.
• A site reached under an alias the host comparison cannot recognize — a LAN IP whose home_url() says localhost, a mapped domain — takes the direct path, so paginated Link targets fail. Growing the list of spellings cannot close that class; the fix belongs at the relay, which knows where a response came from, and is deferred to the all-origins work.
• Whether to relay is decided once, when the editor loads. Re-entering Lockdown Mode with the editor already open — excluding the app and then removing that exclusion — reloads the web view under restrictions the relay is not running for, and REST requests fail until the editor is closed and reopened. Deciding it later means starting the server and reloading the page for it to take effect, since GBKit.networkProxy is read at load; the reverse transition needs nothing, as the relay keeps working once it is up.

Testing Instructions

make test-js
make test-swift-package

Then against a live site, which relays real requests — a write is read back to confirm the record actually changed, Allow is asserted end to end, and ten concurrent requests are fired:

make wp-env-start
WP_ENV_CREDENTIALS_PATH="$PWD/.wp-env.credentials.json" swift test --filter RestRelayIntegrationTests

Manually, in the Simulator with GUTENBERG_FORCE_LOCKDOWN_MODE=1 or on a device with system Lockdown Mode enabled:

1. Open a post, insert an image, and confirm the upload completes and the attachment exists on the site.
2. Insert a link from the toolbar and search for an existing post — results come back.
3. Save, reopen the post, and confirm the content persisted rather than reporting success over an unchanged record.
4. Turn Lockdown Mode off with no media upload delegate configured: no local server starts, and uploads behave as on trunk.