Repository navigation
bug(service-auth): backend→SLM WebSocket 403 handshake rejection (pre-app-auth) — needs live repro (follow-up of #10400) #10459
Description
Follow-up from #10400 (PR #10456). The 4001 token mismatch root cause is durably fixed — the backend role now reads SLM_SECRET_KEY from /etc/autobot/slm-secrets.env and sets backend_jwt_secret so AUTOBOT_JWT_SECRET == SLM_SECRET_KEY every deploy.
Remaining (this issue): the WS handshake is rejected with HTTP 403 before app-level auth. SLM's api/websocket.py never returns 403 (it accept()s then close(4001)), so the 403 originates earlier — likely uvicorn proxy handling (--forwarded-allow-ips), a starlette WebSocketDenialResponse from a route dependency, or the nginx /slm/api/ws/ path on a non-loopback deploy. The co-located backend connects directly to SLM loopback :8000 /api/ws/events. Pinning the exact layer needs runtime reproduction against a live SLM.
Refs: slm_client.py colocated default http://127.0.0.1:8000; #9919 service-auth.
Activity
fix(service-auth): backend→SLM WS 403 — route direct-uvicorn vs nginx…
github-actions commentedon Jun 26, 2026
PR #10522 (merged to
Dev_new_gui) references this issue with a close keyword.If this issue is fully resolved, close it manually. If work remains, no action is needed.
mrveiss commentedon Jun 26, 2026
Merged to
Dev_new_gui(bd9e15f94, PR #10522). Root cause: Docker-ComposeAUTOBOT_SLM_HOST=autobot-slmmade the WS client pick the nginx/slm/prefix path against direct-uvicorn :8000 (no such route) → pre-accept close → uvicorn HTTP 403. Fixed via_is_direct_uvicorn_urlpath selection + reject-context diagnostics on the SLM side. Batch #10440.fix(service-auth): let an nginx port outrank the loopback heuristic w…