Skip to content

fix(config): apply ssh.term to manual /ssh connections (#572) - #573

Merged
billchurch merged 2 commits into
mainfrom
fix/572-ssh-term-client-injection
Aug 18, 2026
Merged

fix(config): apply ssh.term to manual /ssh connections (#572)#573
billchurch merged 2 commits into
mainfrom
fix/572-ssh-term-client-injection

Conversation

@billchurch

Copy link
Copy Markdown
Owner

Summary

Fixes #572WEBSSH2_SSH_TERM / config.ssh.term was only honoured on auto-connect routes (/ssh/host/…, POST, basic auth). A plain /ssh load received no ssh.sshterm, so the client sent its hard-coded xterm-color, and the socket path accepted it without consulting the server default.

Changes

  • app/connectionHandler.ts — new pure buildTermConfig() injects { ssh: { sshterm: config.ssh.term } } on SSH page loads. Only the terminal type is injected (never host/port/credentials). Composed before buildSshCredentials(), so a session fragment overwrites it; buildSshCredentials() now takes the default so a session with no term (e.g. invalid ?sshterm=) still gets config.ssh.term. Telnet routes get nothing (telnet TERM is config.telnet.term).
  • app/socket/adapters/ssh-config.tsbuildTerminalDefaults() falls back to config.ssh.term before TERMINAL_DEFAULTS.DEFAULT_TERM, so clients that omit term honour the operator default too.
  • DocsWEBSSH2_SSH_TERM default corrected to xterm-256color (was documented as xterm-color); precedence (?sshterm= > ssh.term) documented in URL-PARAMETERS.md.

Precedence end-to-end: URL ?sshterm= / session term → config.ssh.term → client/server hard default.

⚠️ Behaviour change

Deployments that never set WEBSSH2_SSH_TERM will see manual /ssh sessions move from xterm-color (client default) to xterm-256color (server default). Auto-connect routes already used xterm-256color, so this aligns the two flows. Chosen over "inject only when explicitly configured" because the reporter's repro sets the value equal to the default, which that variant could not fix without provenance tracking.

Testing

  • tests/unit/connection-handler/term-injection.vitest.ts — 7 cases: manual injection, empty term omitted, telnet omitted, session term wins, session-without-term falls back, nothing when both empty.
  • tests/unit/socket/ssh-config-terminal-defaults.vitest.ts — 4 cases for the fallback chain.
  • npm run lint (0 errors, warnings unchanged from main), typecheck, test (1742 passed), build all clean.
  • Manual: WEBSSH2_SSH_TERM=xterm-256color, curl /ssh"ssh":{"sshterm":"xterm-256color"}; /telnet → no ssh fragment.

No client change required — the client already prefers cfg.ssh.sshterm over its default.

`config.ssh.term` (`WEBSSH2_SSH_TERM`) was only honoured on auto-connect
routes. A plain `/ssh` page load received no `ssh.sshterm`, so the client
sent its own hard-coded `xterm-color`, and the socket path accepted it
without consulting the server default.

- connectionHandler: inject `{ ssh: { sshterm: config.ssh.term } }` on SSH
  page loads (never host/port/credentials); session-supplied term still
  wins; telnet routes unaffected. Session fragments without a term now
  fall back to the configured default.
- ssh-config: `buildTerminalDefaults()` falls back to `config.ssh.term`
  before the hard constant, so clients that omit `term` honour it too.
- docs: correct the `WEBSSH2_SSH_TERM` default (`xterm-256color`, not
  `xterm-color`) and document precedence.

Behaviour change: deployments that never set `WEBSSH2_SSH_TERM` will see
manual `/ssh` sessions move from `xterm-color` to `xterm-256color`, which
aligns them with the auto-connect routes.

Fixes #572
@sonarqubecloud

Copy link
Copy Markdown

@billchurch
billchurch merged commit a64ea6a into main Aug 18, 2026
7 checks passed
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.

[Bug]: defaulted WEBSSH2_SSH_TERM not injected into client config during manual connections

1 participant