mirror of
https://github.com/multica-ai/multica.git
synced 2026-06-17 11:48:42 +02:00
b51d1c4dc3
* fix(cli): make browser-login work from a machine that isn't the server The #923 callback host fix only worked when the CLI and the self-hosted server ran on the same box. In a cross-machine setup — `multica login` from a laptop against a self-hosted server on a NAS — the flow silently wedged on two issues: 1. The callback host was derived from `--app-url`, so the `cli_callback` URL pointed at the server's IP and the browser could never reach the CLI's local listener on the laptop. The OAuth token never came back and subsequent `/api/workspaces` calls 401'd on stale state. 2. `net.Listen("tcp", ...)` on macOS can produce an IPv6-only socket. Browsers and `curl` resolve `localhost`/`127.0.0.1` to IPv4 first and get "connection refused" even when the URL is otherwise correct. Changes: - Derive the callback host from the CLI's own outbound interface by dialing the server (UDP, no packets sent — just asks the kernel which source IP it would use). Falls back to loopback for public app URLs and to the app IP for offline detection. - Add `--callback-host` flag on `login` and `setup self-host` so reverse-proxy / FQDN users can override auto-detection — this is the follow-up @hassaanz asked for on #923. - Pin the callback listener to `tcp4` so macOS never lands on an IPv6-only socket. - `multica setup self-host`: when the user explicitly passes a remote `--server-url` but omits `--app-url`, infer app URL from the server host and warn instead of silently defaulting to `localhost:3000`. Unit tests cover the binding-decision matrix (public, localhost, same- machine LAN, cross-machine LAN, outbound-detect failure, flag override) and the new setup helpers. Reported by @RafeRoberts in #1494 with very clear repro details. * fix(cli): prompt for app_url instead of guessing on remote server_url Per GPT-Boy's review on MUL-1260: deriving app_url as http://<server-host>:3000 breaks for the common api.example.com + app.example.com split and for https-fronted deploys — the setup flow would still open a broken login URL, just slightly later. Replace the guess with an interactive prompt. If the user hits enter (or stdin is unavailable), fail loudly with a clear usage hint instead of proceeding with bad data.