mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 12:22:14 +03:00
384f06aa41
`omniroute login antigravity` already runs the OAuth where it actually works — the operator's own machine, the only place Google's firstparty/nativeapp loopback resolves — but it stopped at PRINTING a credential blob to copy into the remote dashboard by hand. Every piece needed to close that loop was already in place: - `omniroute connect <host>` saves an admin-scoped token in the active context; - `apiFetch()` injects that context's baseUrl + Bearer automatically; - `/api/oauth` requires admin scope (src/server/authz/accessScopes.ts) and stays remote-reachable — routeGuard.ts loopback-gates only `/api/oauth/cursor/auto-import`, with an explicit comment that the rest must remain reachable; - `isAuthenticated()` accepts a Bearer management token; - `/api/oauth/<provider>/paste-credentials` already decodes a blob and persists. So the CLI now POSTs the blob itself whenever the active context points at another machine. No paste, and no SSH tunnel. What it deliberately does NOT do is make the push mandatory. This helper exists because it needs no route to the VPS at all — it talks only to Google, so it works from behind a firewall. A failed push therefore falls back to printing the blob rather than discarding an authorization the operator just completed in a browser. `--no-push` forces the old behaviour, `--push` forces delivery, `--context <name>` targets a specific install. A successful push does not echo the blob: it wraps a refresh token and it already landed. Printing it would only widen the exposure. Note for the follow-up: `oauth start --provider antigravity` cannot substitute for this. `runBrowserFlow` asks the SERVER to start the flow and then polls the server, so the callback still has to reach the server's loopback — it hangs on a remote install exactly like the dashboard does.