feat(gateway): make the IPFS gateway setting actually govern websites and links

[ehsan6sha]

Why

dweb.link now returns HTTP 429 for generated sites once they see real traffic — measured 2026-09-12: a freshly generated site 429'd on dweb.link and returned 200 from Filebase for the same CID at the same moment.

The app already had an IPFS gateway setting. Choosing a different one changed almost nothing:

	before
asset URLs	kept the URL recorded at import time — a later change never reached them
the stable fxfiles.top link	always resolved to dweb
the setting itself	a raw URL text field buried in More → API Configuration, among endpoint overrides no ordinary user should touch

So rather than add a separate per-generation gateway picker, this makes the existing global setting do what it already claims to.

What changed

Settings — the gateway is promoted to its own top-level section under Billing, as a picker (dweb.link / Filebase / Custom…) instead of a URL field. The raw field is removed from More → API Configuration. Two editors for one key would let a near-miss typed in the advanced screen silently demote a preset user to "custom", and with it drop the ?gw= that makes their links follow the choice.

Assets — built from the CID with the current template instead of the URL captured at import time. This was the bug that made the setting look inert.

The stable link — the Worker takes an optional ?gw=, and the app appends it when a link is read, never when the pointer is minted. A pointer is written once and lives for the life of the website, so baking the gateway in would freeze it at whatever was configured that day — exactly the staleness being fixed for assets.

Two deliberate exceptions:

• the URL embedded in a social-media caption does freeze, because the caption is a permanent public artifact;
• the public directory listing URL is left undecorated — the server rejects any URL carrying a query string (isAllowedListingUrl), and one submitter's gateway preference has no business steering a stranger's browser.

?gw= is a fixed allowlist. A user's custom template governs their own asset URLs but is not honoured on the shared link: accepting a caller-supplied destination there would turn a link anyone can share into an open redirector.

Worker hardening found while testing

The Worker had no test coverage, and it fronts every shared link the app has ever minted. Writing tests surfaced five real defects, all now fixed and pinned:

1. ?gw=__proto__ / toString / constructor returned a truthy inherited value from the object literal, whose .cid is undefined. The throw dropped the request onto the IPNS fallback, which does not resolve — so a typo broke the link rather than using the default. Now Object.hasOwn.
2. The CID from w3name is interpolated into the AUTHORITY of the subdomain shape, where a hostile answer containing @ or a backslash could re-point the host. Now charset-checked.
3. A CIDv0 (base58, case-sensitive) or an over-63-char CID cannot be a DNS label (RFC 1035) — both silently corrupt in a subdomain. They now use the path form.
4. An IPNS record may point into a directory; that suffix was being dropped, serving the wrong page.
5. A control character in the record value could split the Location header.

Testing

• flutter test — 1070 passed, 25 skipped
• flutter build web --release -t lib/main_web.dart — ✅ (same command deploy-pages.yml runs)
• flutter analyze on every changed file — No issues found
• node --test cloudflare/ipns-resolver-worker.test.mjs — 33 passed (new)
• 19 new Dart cases for the gateway helper

Reviewed by agy-advisor, which validated the two security fixes and found defects 3 and 4 above. The rest of the advisor panel was unavailable (kimi 403 plan-gated, codex 402, GLM 429, cursor auth-expired, mimo 403).

Reviewer notes

• The two use_build_context_synchronously infos in lib/features/websites/screens/website_detail_screen.dart are pre-existing — they merely shifted five lines from the import added here.
• The Worker is not deployed by this PR. cloudflare/** is not in the Pages trigger; it needs npx wrangler deploy from cloudflare/. The change is backward-compatible in both directions (the old Worker ignores ?gw=; the new one treats a bare link exactly as before), so merge order is safe — but the feature is not visible on shared links until the Worker ships.
• DEFAULT_GATEWAY is left on dweb, per the brief ("dweb.link as default, changeable to filebase"). Given dweb is actively 429-ing, flipping it would rescue links already shared in the wild, which carry no ?gw= — that is a policy call, deliberately left open.

Known limitation (not addressed here)

A site's HTML embeds absolute asset URLs at generation time. Switching the gateway makes the page itself load from the new gateway, but images inside an already-generated site still point at the old one — so an existing 429-ing site needs a fresh generation to fully recover. Making asset references relative (assets in the site's own IPFS directory) is the real fix and belongs in its own change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AwMWmCivEpYTmmzzmjSTAf