mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 04:12:10 +03:00
a61ed5deb1
* fix(oauth): explain the LAN-IP loopback mismatch with an actionable panel #8046 already stops the doomed login when a PKCE_CALLBACK_SERVER_PROVIDERS provider (codex / xai-oauth / grok-cli) is connected from a LAN IP, but it explained itself as one long English sentence rendered in the generic red "Connection failed" step. Two concrete problems with that: - the operator had to parse prose to work out WHICH ports to forward, and the command shipped with `<port>` / `<omniroute-host>` placeholders to resolve by hand; - it forwarded a single port. Both are required: the dashboard port is what makes the origin true-localhost (a LAN origin never reaches the callback-server branch at all), and the provider's fixed callback port is where the browser is actually sent back to. Forwarding either one alone still fails. buildPkceLoopbackMismatchHint() now returns the diagnosis as structured data with the detected host and both ports already filled in, and a dedicated OAuthLoopbackMismatchPanel renders it as: what happened -> how to fix, in three numbered steps with copy-to-clipboard fields. No "Try again" button — retrying the same origin fails identically. The panel yields to the paste-token tab so grok-cli (which is in both provider sets) never stacks the two views. The flat warning string stays exported for non-UI callers. docs: REMOTE-MODE.md gains a "Connecting Codex / Grok on a remote install" section with the fixed-callback table and the two-port tunnel, mirroring the existing Antigravity section. i18n: 9 new oauthModal keys, hand-written for en + pt-BR and propagated to the remaining 40 locales as `__MISSING__:` sentinels (runtime falls back to the clean English value per #7258). * fix(oauth): correct the Antigravity remote-login guidance and drop the stale i18n copy Same LAN-origin family as the codex fix in this branch, different mechanism and a worse failure mode. Google providers (antigravity / agy) have no fixed foreign port: OAuthModal builds `http://127.0.0.1:<dashboardPort>/callback`. On a LAN origin that 127.0.0.1 is the BROWSER's machine, and Google's firstparty/nativeapp consent only releases the code once the loopback is reachable from the approving browser. When it is not, the consent never redirects at all — it hangs. So unlike an ordinary provider there is no error page and no callback URL in the address bar. That made the existing copy actively wrong. `googleOAuthWarning` was corrected when the login helper shipped (#5203), but a changed English value does not invalidate existing translations and `i18n:sync-ui` only fills keys that are ABSENT, never ones that are STALE — so 39 of 43 locales (pt-BR, pt, es, de, fr, ja, zh-CN, …) kept the original "wait for the redirect, copy the full URL and paste it below", instructing a flow that cannot complete. The drift gate that should have caught this is a no-op: `check-translation-drift.mjs` needs `.i18n-state.json`, which is not in the repo, and it runs `--warn`. Because the key's MEANING changed, it is renamed rather than edited — a new key cannot inherit a stale translation. `googleOAuthWarning` is removed from all 43 locales and replaced by 7 `googleLoopback*` keys, hand-written for en + pt-BR and marked `__MISSING__:` elsewhere so the runtime falls back to correct English (#7258). UI: `OAuthGoogleLoopbackNotice` states what is happening and surfaces both real remedies with the detected host and port filled in — the local login helper (recommended; its blob is what the Step 2 field accepts) and a single-port SSH forward. It also REPLACES `remoteAccessInfo` for this family instead of stacking on top of it: that notice promises an error page whose URL you copy, true for ordinary providers and false here. `agy` deliberately gets no helper command. bin/cli/commands/login.mjs pins PROVIDER = "antigravity" and parsePastedCredentials() rejects a blob whose embedded provider does not match the route provider, so advertising the helper there would send the operator to a blob guaranteed to be refused. It keeps the tunnel path. Refactor: the shared `resolveDashboardPort` / `buildSshLocalForward` helpers move to `loopbackTunnel.ts`, used by both hint builders. The codex builder's behaviour is unchanged (its 11 tests still pass untouched). docs: REMOTE-MODE.md notes that the dashboard now surfaces the remedies, states that one forward is enough for Antigravity (contrasting the two-port codex case), and aligns Option B's command on 127.0.0.1 to match what the UI generates. --------- Co-authored-by: ikelvingo <im.kelvinwong@gmail.com>