mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[PR #23604] [CLOSED] fix: include token in terminal orchestrator websocket URL #42905
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/23604
Author: @kaplanmaxe
Created: 4/11/2026
Status: ❌ Closed
Base:
dev← Head:fix-terminal-orchestrator-ws-auth📝 Commits (2)
44963f2fix: include token in terminal orchestrator websocket URL3cabedefix: restore x-session-id header forwarding in terminal proxy📊 Changes
3 files changed (+80 additions, -20 deletions)
View changed files
📝
backend/open_webui/routers/terminals.py(+12 -20)➕
backend/open_webui/test/util/test_terminals.py(+44 -0)➕
backend/open_webui/utils/terminals.py(+24 -0)📄 Description
Pull Request Checklist
Note to first-time contributors
I did not open a discussion before submitting this fix because this is a narrow bugfix with a focused regression test and manual validation, not a large feature or architectural change.
Before submitting, make sure you've checked the following:
devbranch.fixprefix.Description
This PR fixes terminal WebSocket proxy connections to the terminals orchestrator by including the bearer token in the upstream WebSocket query string.
Today
Open WebUIopens the upstream terminal WebSocket withuser_idonly, then sends an auth message after the connection is established. The terminals orchestrator validates bearer auth during the WebSocket handshake, so the connection is rejected with403before that auth frame can be sent.This patch:
tokento the upstream WebSocket query params for bearer-auth terminal connectionsRepro / Root Cause
When
Open WebUIis configured to use the terminals orchestrator, terminal session creation succeeds but interactive attach fails with a WebSocket handshake error:In my case, the failure was reproducible because:
POST /api/terminalssucceededtokenfailed with403?token=...&user_id=...succeededSo the issue is isolated to the upstream WebSocket auth shape.
The root cause is that the terminals orchestrator validates WebSocket auth during the handshake and expects the bearer token to be present on the upstream WebSocket request.
Open WebUIwas building the upstream WebSocket URL with only:user_idand then sending:
{"type":"auth","token":"..."}after the socket connected.
That does not work when the upstream rejects the handshake before accepting the connection.
Testing
Unit tests
Result:
Manual validation
I am also running this successfully in a Kubernetes cluster using the terminals orchestrator flow.
Tested setup:
ghcr.io/open-webui/terminals:0.0.2ghcr.io/open-webui/terminals-operator:0.0.2ghcr.io/open-webui/open-terminal:0.11.34Open WebUIconfigured to connect to the orchestrator service over the in-cluster service URLBefore this patch:
WSServerHandshakeError: 403After this patch:
Open WebUIinterfaceI also reproduced the orchestrator behavior directly by connecting to the orchestrator WebSocket endpoint:
tokenin the query string:403tokenin the query string: connection succeedsEdge cases covered by tests
tokentokenChangelog Entry
Description
Added
Changed
tokenwhenauth_type == "bearer"and a key is present.Deprecated
Removed
Fixed
403because the bearer token is missing from the query string.Security
Open WebUI's upstream WebSocket auth behavior with the orchestrator's existing handshake validation requirements.Breaking Changes
Additional Information
Screenshots or Videos
Contributor License Agreement
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.