fix(auth): extension CoinPay sign-in never picked up the session

[ralyodio]

The bug

Clicking Sign in with CoinPay in the extension's options page (chrome-extension://…/options.html) signs the website in and leaves the extension signed out — exactly the reported "tronbrowser.dev is authed but not the web extension".

Root cause

coinpay-auth.js asked the backend to redirect back to chrome.identity.getRedirectURL() → https://<ext-id>.chromiumapp.org/.

That target is off-origin, so safeRedirect() rejected it — correctly, since the session token rides in the redirect fragment. With the redirect dropped, /api/auth/coinpay/callback fell through to c.redirect(${APP_URL}/?signedin=1). The OAuth dance completed, tronbrowser.dev got its tb_session cookie, and the extension got nothing.

Ungoogled Chromium independently rewrites chromiumapp.org to a non-resolving .qjz9zk host, so launchWebAuthFlow could not have worked either. bittorrented.js already worked around this via ext-callback; CoinPay never got the same treatment.

The fix

• New GET /api/auth/ext-login — validates an on-origin callback, and when the user is already signed in on the website hands a session straight back rather than running CoinPay a second time. Otherwise forwards to the CoinPay dance, preserving the callback.
• coinpaySignIn() opens that URL in a normal tab and waits for the token, matching the bittorrented flow. The storage listener is registered before the tab is created so a fast redirect can't race it.
• ext-callback.js now serves both flows, keyed on ?src=tb (tbAuthToken vs btrToken); background.js handles the generalized ext-token message.
• Dropped the now-unused identity permission from the manifest.

Decision logic lives in services/api/src/ext-login.ts so it's unit-testable — index.ts calls serve() at import and can't be imported from a test.

Security

Redirect targets remain same-origin only. A drive-by top-level navigation to /api/auth/ext-login mints a token that lands in the fragment of a URL on our origin, which the navigating site cannot read. Covered by tests, including an explicit case rejecting the chromiumapp.org URL that caused this.

Verification

• vitest run in services/api — 57 passed (9 files), including 5 new ext-login tests
• tsc --noEmit — clean
• eslint on all changed files — 0 errors (8 pre-existing any warnings on untouched lines)
• Extension JS syntax-checked; manifest re-parsed

Not verified: a live browser round-trip through CoinPay — that needs real OAuth credentials.

Note for the release

This is unreleased, so tronbrowser update correctly reports "already up to date (v3.8.3)" — there is nothing newer to pull yet. This needs to ship in v3.8.4 before it reaches anyone.

Separately worth a look: COINPAY_REDIRECT_URI defaults to https://tronbrowser**.com**/api/auth/coinpay/callback (services/api/src/index.ts:20) while APP_URL defaults to tronbrowser.dev. Left alone here since production presumably sets the env var, but if it doesn't, that's a second broken hop.

🤖 Generated with Claude Code

---

Second commit: unbreaking CI (unrelated to the auth fix)

build was already failing on main before this branch existed — CI went red at 5bad141 (#48, Moshpit resolve); #47 before it was green.

noUncheckedIndexedAccess types the destructured label/tld in parseRegistryName as string | undefined, because TS can't narrow an array to a 2-tuple from a parts.length !== 2 check. Four TS2345/TS2322 errors failed apps/desktop and took the whole pnpm -r build down with it.

Fixed with an explicit guard. Behavior is unchanged: length 2 already guarantees both values exist, and an empty label would fail LABEL.test() on the very next line.

It's scope bleed, but the PR could not go green without it — and neither could anything else landing on main.

Full workspace verification after both commits:

• pnpm -r build — exit 0
• pnpm -r test — exit 0, 22 packages
• pnpm lint — exit 0 (warnings only, all pre-existing)
• CI on this branch: build pass (first green build since feat(resolve): choose whether Moshpit overrides clearnet for a contested name #48), package pass, security review pass, Socket pass

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.