Skip to content

rebase(desktop): kaushik-IDE onto main (SSH tunnel + CORS) - #38

Draft
venkateshsakamuri-lab wants to merge 2 commits into
mainfrom
cursor/rebase-kaushik-ide-on-main-6474
Draft

rebase(desktop): kaushik-IDE onto main (SSH tunnel + CORS)#38
venkateshsakamuri-lab wants to merge 2 commits into
mainfrom
cursor/rebase-kaushik-ide-on-main-6474

Conversation

@venkateshsakamuri-lab

Copy link
Copy Markdown
Contributor

Summary

Rebases Kaushik’s kaushik-IDE desktop work onto latest main so the SSH-tunnel desktop client picks up main’s agent-runtime and related fixes.

kaushik-IDE was also force-updated to the same tip (b7037f1) after a clean rebase (no conflicts).

Commits on top of main

  1. desktop-client init — DeepSQL Desktop Electron thin client (TLS + SSH tunnel)
  2. fix(desktop): allow loopback origins so tunnel connections pass CORS — probe sends Origin, loopback port wildcards in CORS defaults, clearer cors-rejected errors

Why

Main landed agent-runtime / self-host / CLI fixes after the desktop branch diverged. Rebase keeps the desktop + CORS tunnel fix while inheriting those.

Test plan

  • git rebase origin/main clean (no conflicts)
  • npm run selftest:tunnel in desktop/ (14/14)
  • npm run smoke via real SSH → frontend :3000
  • CORS E2E: Origin-bearing GET + POST through tunnel (no Invalid CORS request)
  • GUI: launcher Test → Connect → workspace loads over SSH
  • Spot-check Agent tab against main’s agent-runtime fixes (Hermes if available)

Notes

  • Deployments that set CORS_ALLOWED_ORIGINS must keep http://127.0.0.1:*,http://localhost:* alongside the public hostname, or tunnel logins 403.
  • Vite for native/dev must bind IPv4 (--host 127.0.0.1) because the tunnel forwards to 127.0.0.1.
Open in Web Open in Cursor 

K. Kaushik Reddy and others added 2 commits August 9, 2026 13:30
Connecting to a VM through the SSH tunnel failed with "Request failed with
status code 403" as soon as the user tried to log in.

The tunnel serves the web app from http://127.0.0.1:<sticky port>, not the
VM's hostname, and a self-host deployment that sets CORS_ALLOWED_ORIGINS to
its public hostname replaces the built-in list rather than extending it. Spring
treats any request carrying Origin as cross-origin (the same-origin
short-circuit went away in 5.3), so the backend answered 403 with the
plain-text body "Invalid CORS request". That body has no `message` field, so
client.js's axios interceptor fell through to axios's own wording — an error
naming neither CORS nor the origin.

It hid well: Chromium omits Origin on same-origin GETs, so the health probe,
the SPA and every read succeeded and the connection tested green. Only the
first POST — the login — failed.

- probe.js sends an Origin header, so the rejection is caught at connect time
  rather than at the user's first login, and transport.js reports it as
  `cors-rejected` naming the origin and the exact allowlist to set.
- Loopback entries in the shipped defaults now carry a port wildcard, since
  the tunnel's local port is chosen at runtime. Legal only because
  SecurityConfig uses setAllowedOriginPatterns.
- .env.example, docker-compose.yml and desktop/README.md spell out that
  CORS_ALLOWED_ORIGINS replaces the list, which is how the loopback entries
  go missing.
- CLAUDE.md and config.js drop the "zero backend changes" claim: CORS is the
  one setting the thin client does require.
- tunnel-selftest.js grows two checks (14/14) covering the Origin header and
  a 403 from an allowlist that omits the origin.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@venkateshsakamuri-lab

Copy link
Copy Markdown
Contributor Author

@urstrulykkr do you wanna rebase again on main latest, fix the developer tool issues and raise PR again?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant