Security: Replace JWT tokens in WebSocket URLs with one-time-use tickets

[Copilot]

JWT tokens in WebSocket query params (?token=...) expose credentials in server logs, proxy logs, and browser history. This PR implements a ticket-based authentication flow where clients first obtain a short-lived ticket via REST, then connect with that ticket.

Changes

New ticket service (WebSocketTicketService)

• Generates UUID tickets stored in Redis with 30s TTL
• Validates and immediately evicts tickets on use (one-time)

New endpoint POST /api/auth/ws-ticket

• Requires Authorization: Bearer <JWT> header
• Returns { success: true, ticket: "<uuid>" }

WebSocket handler updates (ChatWebSocketHandler)

• Renamed extractUsernameFromJWT → extractUserFromTicket
• Now looks for ?ticket= param instead of ?token=
• Removed anonSessionId query param fallback (cookies-only now)

Usage

# 1. Get ticket
POST /api/auth/ws-ticket
Authorization: Bearer <JWT>

# 2. Connect within 30 seconds
ws://host/ws/chat?ticket=<ticket>

Testing

• Added unit tests for WebSocketTicketService covering ticket generation, validation, consumption, and edge cases

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• esm.ubuntu.com
  • Triggering command: /usr/lib/apt/methods/https /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Security: Harden WebSocket Connection Logic</issue_title>
<issue_description>### Description
The ChatWebSocketHandler has two potential issues:

1. Token in Query Param: extractUsernameFromJWT looks for the JWT in a query parameter (?token=...). This is a common pattern, but it's less secure than using headers (which WebSockets don't easily support) or a one-time ticket system. The token can be logged in server logs, proxy logs, and browser history.
2. Anonymous ID Extraction: extractAnonSessionId tries to get the ID from cookies, but falls back to a query parameter (?anonSessionId=...). This is flexible but also creates two different ways to connect.

A more secure approach for authenticated users is to have them hit a standard REST endpoint (/api/ws/ticket) to get a short-lived, one-time-use ticket, and then connect to the WebSocket with ?ticket=....

Acceptance Criteria

1. Create a new endpoint (e.g., POST /api/auth/ws-ticket) that is secured (requires Authorization header).
2. When a user hits this endpoint, generate a short-lived (e.g., 30 seconds), one-time-use ticket (e.g., a random UUID) and store it in Redis or a cache with the user's email/ID as the value (e.g., cache.put(ticket, email)).
3. Modify ChatWebSocketHandler.extractUsernameFromJWT:
   • Rename it to extractUserFromTicket.
   • Change it to look for a ticket query parameter.
   • Validate the ticket against the cache. If it exists, retrieve the user's email/ID and immediately evict the ticket from the cache to prevent reuse.
4. Remove the token query param logic.
5. Update documentation (README.md) to reflect this new, more secure connection flow for authenticated users.
6. The anonSessionId logic can remain as-is, but the query param fallback should be considered for removal in favor of cookies-only.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Security: Harden WebSocket Connection Logic #21

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.