• exec/websocketservice.js

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Jul 25 17:53:21 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/12951b03152f018744441521
    Modified Files:
    exec/websocketservice.js
    Log Message:
    websocketservice.js: a client disconnect isn't an error

    A short write means the peer went away, which is the normal way a
    WebSocket proxy session ends - not an exception. SendToServer() and SendToWebSocketClient() now return false in that case and the proxy loop breaks, matching how the existing null returns from GetFromServer() / GetFromWebSocketClient() are already handled. The failure is logged at LOG_DEBUG instead of surfacing in data/error.log:

    srvc 3408 WSS Error: SendToWebSocketClientVersion7 only sent 0 of
    138 bytes

    The throws were added in 1f087a43ce9 (rejected-29-rule).

    The literal "0" in that message is specific to a TLS (WSS) session: js_socket_sendsocket() returns -1 on a plaintext socket error but a byte
    count for every TLS outcome, so JS can't tell a closed connection from a
    short write. Tracked separately as GitLab #1199.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sun Aug 16 22:55:13 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/d9f3abd619d4bdd8e0a6b8de
    Modified Files:
    exec/websocketservice.js
    Log Message:
    websocketservice.js: name the authenticated web session in the sidecar

    The relay already drops a sidecar file beside each connection so the
    target service can learn the client's real IP, which a service reading
    a proxied socket cannot see for itself. It said where a client came
    from and nothing about who they were, so every browser arrived at the
    far end anonymous, and a service had no way to tell an authenticated
    visitor from a passer-by.

    The Cookie header is captured during the handshake, the session
    resolved against data/user/####.web, and the user number written as a
    second line of the sidecar. A dead or absent session is user zero,
    which is the truthful answer rather than a refusal: what a service does
    with an anonymous client is the service's decision, not the relay's.

    THE ORDERING IS THE GUARANTEE, and it is why this is worth stating in
    the code as well as here. The sidecar is written and closed before a
    single byte is forwarded. So a target service that has been spoken to
    and still finds no sidecar knows it is not talking to the relay at all,
    and can treat that connection as a direct local one. Written after the
    first byte, that inference would be a race, and the fallback for a
    missing sidecar is exactly the trusting one.

    An over-long handshake header line is now refused rather than
    truncated. A line cut at the buffer size leaves its tail to be parsed
    as the NEXT header, which in this file's case can walk a value into the
    slot the user number is read from. Refusing is the only safe reading of
    a line that did not fit.

    -auth is new, and refuses any connection whose sidecar cannot be
    written. Without it a failed write degrades to a connection with no
    sidecar, which is precisely the shape the fallback above treats as
    trusted and local -- a write error turning into an unauthenticated
    client wearing a local client's clothes.

    Backward compatible: without -auth the file keeps its old single-line
    meaning to anything that only reads the first line, and the behaviour
    of every existing caller is unchanged.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net