Remove obsolete auth token handling after gateway sandbox deployment

[sanity]

Context

freenet/freenet-core#3254 adds iframe sandbox isolation to the Freenet gateway. The gateway now handles auth token injection transparently via a postMessage bridge, so River no longer needs to read or pass the auth token itself.

What to remove

1. get_auth_token_from_window() in ui/src/components/app.rs (~line 222-243) — reads window.__FREENET_AUTH_TOKEN__ which is no longer injected. Now always returns None.

2. Manual authToken URL parameter appending in ui/src/components/app/freenet_api/connection_manager.rs (~line 42-55) — the gateway bridge injects the token automatically. This code path is now a no-op since the token is always None.

3. localStorage usage for invitations, notifications, and migration flags — sandboxed iframes have an opaque origin with no localStorage access. These should migrate to Freenet delegates or be removed if no longer needed.

4. BroadcastChannel multi-tab detection — won't work across opaque origins. Consider whether this feature is still needed or can use an alternative mechanism.

When

After freenet-core 0.1.149+ (with the sandbox fix) is deployed and confirmed working.

Related

• fix: sandbox contract web apps in iframes for origin isolation freenet-core#3254 (the sandbox isolation PR)
• GHSA-824h-7x5x-wfmf (the security advisory)

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-03-05T15:26:12.200386425+00:00
Issue hash: 963459fd

Value Assessment

Removing the window-level token harvesters is user-facing because the gateway sandboxed build no longer exposes window.__FREENET_AUTH_TOKEN__, yet get_auth_token_from_window() in ui/src/components/app.rs:222 still tries to read it and initialize_connection in ui/src/components/app/freenet_api/connection_manager.rs:41 still appends ?authToken= when the token is present. The gateway now injects the token through the secure postMessage bridge, so that combination is dead code at best and, without changes, the UI never stops checking for something that will never exist in the sandboxed path. More critically, the same sandbox isolates the iframe from localStorage, so features that persist invitations, notification prompt state, and migration flags in storage break completely—save_invitation_to_storage in ui/src/components/room_list/receive_invitation_modal.rs:12, the notification prompt tracking around ui/src/components/app/notifications.rs:122, and the legacy-migration guard in ui/src/components/app/chat_delegate.rs:481 all silently fail to read or write, meaning invite recovery, notification UX, and delegate migration retries stop working for everyone using the sandboxed gateway.

Strategically, fixing these gaps aligns with River’s goal of being a secure Freenet-native client. Keeping broadcast-channel multi-tab detection (ui/src/components/app/tab_detection.rs:80) and persistent migration/state flags in place would leave River incompatible with the hardened gateway that now creates an opaque origin, undermining the security improvements targeted by freenet-core#3254. Relying on unauthorized storage channels makes the app brittle as soon as the sandbox rollout completes, so removing the obsolete token plumbing and replacing the persistence pieces with delegate-backed or WebSocket-based alternatives keeps River aligned with the “zero-trust” UI architecture the gateway team has just shipped.

The blocking factor is also concrete: until the UI stops depending on localStorage, the legacy-migration logic will keep retrying on every reconnect because it can no longer record that the migration already happened, and notification permission prompts will either never re-run or will keep firing even after the user answered, creating noise that masks other issues. Invitations stored for post-reload recovery simply disappear with sandboxed storage, so anyone who reloads while handling an invite loses their progress. These regressions directly impact core flows—joining rooms, receiving notifications, and delegate migrations—and therefore strain ongoing development and QA until the storage/access touches are rewritten.

Urgency comes from the fact that the sandbox fix has already landed in freenet-core 0.1.149+, so as soon as River switches to that gateway build (and the issue even notes “after … deployed and confirmed”), every sandboxed River client experiences these regressions. Once the Freenet gateway deploys the sandbox to production, River needs this cleanup to stay functional; the sooner it is resolved after that deployment, the shorter the window in which users suffer broken invites, errant migration noise, and unusable notification prompts.

Cost Assessment

Scope is moderate but crosscuts several UI subsystems. Removing the obsolete get_auth_token_from_window() helper in ui/src/components/app.rs:222-243 and the auth-parameter plumbing in ui/src/components/app/freenet_api/connection_manager.rs:46-210 is mostly surgical, but those hooks also guard the reconnection logic that currently writes/reads the river_last_auth_reload flag from localStorage. Beyond that, every single localStorage consumer mentioned in the issue (invitation recovery in ui/src/components/room_list/receive_invitation_modal.rs:1-90, notification prompt tracking in ui/src/components/app/notifications.rs:80-180, receive-time caching in ui/src/components/app/receive_times.rs:12-104, and the legacy delegate migration flag in ui/src/components/app/chat_delegate.rs:470-540) either needs removal or a replacement persistence channel. The BroadcastChannel-based tab detection in ui/src/components/app/tab_detection.rs:1-106 is another subsystem that will break under an opaque origin, so the issue touches multiple files, two distinct helper modules, and the overall strategy for storing short-lived UI state or enforcing “primary tab” semantics.

The technical work isn’t just deleting code; it requires deciding how to replace the missing browser primitives. Invitations currently persist across reloads via localStorage, so removing that state (or moving it to a delegate-backed store) means adding fetch/store APIs against Freenet delegates or rearchitecting the pending invite workflow so the UI never needs to survive a reload. Notification prompts and receive-time caching are similar: their lightweight localStorage format can’t run inside a sandboxed iframe, so the alternate could be storing those timestamps and flags in the existing synchronizer state or a delegate, which is non‑trivial because the code assumes synchronous local access (storage.set_item/get_item). The tab-election logic in tab_detection.rs:1-106 has opaque-origin implications, meaning we must judge whether a replacement notification (perhaps via a delegate that tracks “primary tab” per user) is worth the added complexity; it will likely require asynchronous consensus and event hooks similar to the current BroadcastChannel callbacks, so it is not a simple drop-in change.

Risk is elevated because these features are user-visible. If invitation persistence goes away without a delegate replacement, reloading the UI could permanently drop pending invites; failing to persist the legacy migration flag will cause repeated expensive delegate lookups (chat_delegate.rs:470-540), and losing the notification prompt flag forces the UI to spam permission requests on every message. The reconnection guard that writes river_last_auth_reload also protects against infinite reload loops (connection_manager.rs:86-210), so removing that storage without another guard risks leaving the UI in a bad error state after a node restart. Testing will therefore need to go beyond unit checks: the migration should be exercised in a browser build to confirm invites still survive reloads (e.g., reproduce the invite modal flow), that notification prompt requests only happen once, and that reconnection still behaves when AUTH_TOKEN_INVALID occurs. Multi-tab behavior should also be manually verified or covered by some integration test to ensure a fallback to read-only mode is still enforced under the sandboxed origin.

---

Generated by issue-prioritizer