mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-28 22:17:48 +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.
28 lines
661 B
Go
28 lines
661 B
Go
package main
|
|
|
|
import "testing"
|
|
|
|
func TestServerHostIsLocal(t *testing.T) {
|
|
cases := []struct {
|
|
name string
|
|
server string
|
|
want bool
|
|
}{
|
|
{"localhost", "http://localhost:8080", true},
|
|
{"127.0.0.1", "http://127.0.0.1:8080", true},
|
|
{"IPv6 loopback", "http://[::1]:8080", true},
|
|
{"LAN IP", "http://192.168.0.28:8080", false},
|
|
{"public FQDN", "https://api.internal.co", false},
|
|
{"unparseable", "://bad", false},
|
|
}
|
|
for _, tc := range cases {
|
|
tc := tc
|
|
t.Run(tc.name, func(t *testing.T) {
|
|
if got := serverHostIsLocal(tc.server); got != tc.want {
|
|
t.Errorf("serverHostIsLocal(%q) = %v, want %v", tc.server, got, tc.want)
|
|
}
|
|
})
|
|
}
|
|
}
|
|
|