Misleading 'hack attempt?' log message when session cookie is unavailable

[gretta-bot]

Summary

When a websocket reconnection occurs without the session cookie (e.g., due to cookie expiration, browser settings, or proxy stripping cookies), Solara logs a CRITICAL level message suggesting a potential hack attempt:

Session id mismatch when reusing kernel (hack attempt?): <original-session-id> != session-id-cookie-unavailable:<uuid>

This is misleading because the most common cause is simply a missing cookie, not a security threat.

Root Cause

In solara/server/starlette.py (line ~317), when the session cookie is unavailable, a fallback ID is generated:

if not session_id:
    logger.warning("no session cookie")
    session_id = "session-id-cookie-unavailable:" + str(uuid4())

Later in solara/server/kernel_context.py (line ~477), when reusing a kernel, this mismatched ID triggers the alarming log:

if context.session_id != session_id:
    logger.critical("Session id mismatch when reusing kernel (hack attempt?): %s != %s", context.session_id, session_id)

Common Scenarios (Not Hacks)

1. Cookie expiration - Session cookie expired between initial connection and reconnect
2. Browser cookie settings - Third-party cookie blocking
3. SameSite attribute issues - Cookie not sent on websocket upgrade
4. Proxy/load balancer - Stripping cookies on websocket connections
5. Cross-origin restrictions - Different domain for dashboard vs websocket

Suggested Improvements

1. Differentiate the log message when the incoming session starts with session-id-cookie-unavailable: — this clearly indicates a missing cookie, not session hijacking
2. Lower the log level from CRITICAL to WARNING for the cookie-unavailable case
3. Improve the message to something like: Session cookie was not available during websocket reconnection (possible cookie expiration or browser settings)

Environment

• Solara version: 1.57.2
• Running behind nginx reverse proxy with websocket support