Skip to content

fix(dashboard): allow websocket clients for public binds#32614

Closed
cbjerg wants to merge 1 commit into
NousResearch:mainfrom
cbjerg:fix/dashboard-public-bind-websockets
Closed

fix(dashboard): allow websocket clients for public binds#32614
cbjerg wants to merge 1 commit into
NousResearch:mainfrom
cbjerg:fix/dashboard-public-bind-websockets

Conversation

@cbjerg

@cbjerg cbjerg commented May 26, 2026

Copy link
Copy Markdown

Summary

  • allow dashboard WebSocket clients from non-loopback peers when the dashboard is explicitly bound to a non-loopback interface
  • keep loopback-bound dashboards restricted to loopback WebSocket clients
  • add regression coverage for public-bind vs loopback-bind client checks

Why

A recent hardening change made dashboard WebSockets loopback-only. That is correct for the default localhost bind, but it breaks the existing LAN dashboard use case when the operator explicitly starts the dashboard with e.g. hermes dashboard --host 0.0.0.0 --insecure --tui: the HTTP UI loads remotely, but /api/events, /api/ws, and /api/pty are rejected, causing the chat sidebar to show events feed disconnected.

Test Plan

  • python -m pytest tests/hermes_cli/test_web_server_host_header.py -q
  • manually verified /api/events connects from 127.0.0.1:9119 and LAN addresses after restarting the dashboard

@teknium1

Copy link
Copy Markdown
Contributor

Closing as superseded by #35141, which fixed the same WebSocket-on-insecure-bind issue via #33278. Both PRs took the same approach (open the WS peer check on a public bind); we went with the wildcard-only variant. Thanks for the contribution and for surfacing this.

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

Labels

comp/tui Terminal UI (ui-tui/ + tui_gateway/) P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants