Fork: Chrome/macOS login fix + exit-node picker & management UI

[iazat]

Hi! 👋

I reworked this extension to get it running smoothly on Chrome / macOS and added a few things that have come up in issues here. Sharing in case it's useful to others.

What I changed / added

• Working login on Chrome/macOS — the popup's "Log in" link was a dead anchor (#login with no handler); it now opens the auth flow. Also fixed Chrome-vs-Firefox detection during --install (newer Chrome also defines browser, so the install command was wrongly generated as Firefox).
• Exit-node picker — pick or clear a per-profile exit node right from the popup (related: Question: Use exit nodes #5, FR: Use an exitnode on certain sites automatically #3).
• Management page at http://100.100.100.100/ — device status, tailnet machine list (address / OS / online), exit-node selector, and a Log out button, so logging out no longer requires removing & re-adding the extension.
• Honest transient states — "Connecting…" / "Waiting for approval…" while the link comes up, instead of an error flash right after login.
• Shipped the missing need-install icon and added a live popup refresh after login.

Repo: https://github.com/iazat/ts-browser-ext

If you'd like, I'm happy to split any of these into focused PRs against this repo — just say which ones are interesting and I'll send them in.

[bradfitz]

@iazat, those all sound good if they're broken up into small focused PRs.

But how did you get the http://100.100.100.100 page working? IIRC I tried that but it looked like I was going to make changes in the tailscale.com web handler code to adapt the auth mode.

[iazat]

@bradfitz yep, will break them into small focused PRs.

For the 100.100.100.100 page — I didn't touch the web client or its auth mode at all. I dropped the web.Server in LoginServerMode and stopped routing 100.100.100.100 through ws.ServeHTTP. Now the backend serves its own little page there plus a small JSON API. The API just calls localapi through tsnet's LocalClient: Status() for the data, EditPrefs() with ExitNodeIP for the exit-node picker, and Logout() for the logout button.

That's what sidesteps the auth wall you ran into. Requests to 100.100.100.100 come in over the local HTTP proxy from 127.0.0.1, so both ends are the same trusted process — there's no remote node to WhoIs. ManageServerMode does a WhoIs(r.RemoteAddr) and expects a tailnet-authed browser session, which is exactly the part you'd have had to adapt. I just skipped that handler instead of reworking it.

Tradeoff: it's a hand-rolled page, not the real web UI. For status + machine list + exit node + logout that was enough; anything richer would mean rebuilding what the web client already gives you.

[bradfitz]

Ah, okay. That's probably fine for now. But changing the official web UI is also okay if you're game. (cc @willnorris)

[iazat]

Sounds good @bradfitz — I'm game to try the official web UI route.

I'll keep it behind an explicit opt-in so it can't loosen auth for the normal tailscaled-served web client.

[iazat]

quick follow-up before i start, mostly to nail down the api shape w/ @willnorris.

most of the manage UI is actually already there — tsnet sets RunWebClient and calls ConfigureWebClient, so the official web client already runs in ManageServerMode with NewAuthURL/WaitAuthURL wired to control. so no need to rebuild the auth-url flow.

the only real blocker is authorizeRequest -> setPeer -> WhoIs(r.RemoteAddr). the ext serves the page over a loopback proxy, so requests come from 127.0.0.1, WhoIs returns errNotUsingTailscale, and you get "must access over tailscale".

proposed shape (open to changes):

1. client/web: an explicit opt-in on ServerOpts, smth like LocalProxyTrusted bool. when set, authorizeRequest skips the session check and setPeer synthesizes the self node w/ owner caps instead of calling WhoIs. off by default so the normal tailscaled-served web client doesnt change at all.
2. tsnet: a small accessor to reach the already-built handler (webClientGetOrInit is unexported rn), so the ext can route 100.100.100.100 to the real UI instead of my hand-rolled page.

does that direction look ok, and is LocalProxyTrusted a sane name? if so i'll send it as two small PRs (client/web opt-in + tsnet accessor) then switch the ext over.

[iazat]

small addition re: the api shape — there's already a precedent for non-tailnet auth in authorizeRequest: the Synology/QNAP branches skip WhoIs and authorize by platform instead. so LocalProxyTrusted would just be a third case next to those, not a new concept. and for caps we dont need to invent anything — when we synthesize the self node we can reuse the existing owner path (peerCapabilities{capFeatureAll: true} in auth.go), same as a user-owned node managed by its owner.

fwiw the tailscale web cli itself only runs Login/ReadOnly mode over localhost, never Manage — so this loopback-trust case genuinely isnt covered anywhere yet.

(cc @willnorris)