Bug: SSH session is shared accross all open terminal windows #1

Closed
opened 2025-10-12 14:39:15 +00:00 by Rtch · 0 comments
Owner

Currently, if a user has multiple terminal windows open, running the ssh command in one terminal causes all other open terminals to also enter that remote session. This is incorrect. Each terminal should represent an independent session.

Expected Behaviour:
Each terminal window should maintain its own independent session. An ssh command in one terminal should not affect any other terminal

Actual Behaviour:
All terminals for a single player share the same server-side session state. ssh'ing in one terminal effectively hijacks the session for all other terminals.

Steps to Reproduce:

  1. Launch the game and create an account.
  2. From the launcher menu, open a second terminal window.
  3. In the first terminal, connect to a remote machine (i.e., ssh 8.8.8.8). The scrollback will confirm connection.
  4. Switch to the second terminal window and type a command such as 'ls'.
  5. Observe that the 'ls' command is executed on the remote machine, not the home machine.

Cause:
This is caused by an architectural issue on the server. The server-side Player object currently maintains only a single 'CommandProcessor' instance. This instance holds all session state (i.e., the current machine, the current directory). All terminals opened by a client are funneled into this single, shared CommandProcessor.

Solution:

  1. Introduce server-side 'Sessions':
  • Refactor the CommandProcessor class into a 'Session' class.
  • The Player will need to be updated to manage a collection of 'Session' objects (in a map?), with one Session for each client-side terminal.
  1. Update the Network Protocol:
  • A 'session_id' will need to be added to all relevant client-server messages (i.e., C2S_COMMAND, S2C_COMMAND_RESPONSE) to identify which session a command belongs to and which terminal a response is for.
  • New messages will be required for the client to request the creation of a new session when a terminal is opened.
  1. Update Client:
  • Client-Side terminal object should be responsible for requesting a new session from the server on creation.
  • 'Terminal' will store its unique 'session_id' and include it in all commands sent to the server.
  • Client's main message loop will need updating to use the 'session_id' from server responses to route them to the correct Terminal window.
Currently, if a user has multiple terminal windows open, running the ssh command in one terminal causes all other open terminals to also enter that remote session. This is incorrect. Each terminal should represent an independent session. Expected Behaviour: Each terminal window should maintain its own independent session. An ssh command in one terminal should *not* affect any other terminal Actual Behaviour: All terminals for a single player share the same server-side session state. ssh'ing in one terminal effectively hijacks the session for all other terminals. Steps to Reproduce: 1. Launch the game and create an account. 2. From the launcher menu, open a second terminal window. 3. In the first terminal, connect to a remote machine (i.e., ssh 8.8.8.8). The scrollback will confirm connection. 4. Switch to the second terminal window and type a command such as 'ls'. 5. Observe that the 'ls' command is executed on the remote machine, not the home machine. Cause: This is caused by an architectural issue on the server. The server-side Player object currently maintains only a single 'CommandProcessor' instance. This instance holds all session state (i.e., the current machine, the current directory). All terminals opened by a client are funneled into this single, shared CommandProcessor. Solution: 1. Introduce server-side 'Sessions': * Refactor the CommandProcessor class into a 'Session' class. * The Player will need to be updated to manage a collection of 'Session' objects (in a map?), with one Session for each client-side terminal. 2. Update the Network Protocol: * A 'session_id' will need to be added to all relevant client-server messages (i.e., C2S_COMMAND, S2C_COMMAND_RESPONSE) to identify which session a command belongs to and which terminal a response is for. * New messages will be required for the client to request the creation of a new session when a terminal is opened. 3. Update Client: * Client-Side terminal object should be responsible for requesting a new session from the server on creation. * 'Terminal' will store its unique 'session_id' and include it in all commands sent to the server. * Client's main message loop will need updating to use the 'session_id' from server responses to route them to the correct Terminal window.
Rtch added the
Kind/Bug
Reviewed
Confirmed
Priority
High
labels 2025-10-12 14:39:15 +00:00
Rtch self-assigned this 2025-10-12 14:39:15 +00:00
dacav was assigned by Rtch 2025-10-12 14:39:15 +00:00
Rtch closed this issue 2025-10-20 19:17:06 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Rtch/bettola#1
No description provided.