[Regression] PR #1311 still selects Apple VNC auth after banner normalization

Title

PR #1311 still selects Apple VNC auth after banner normalization

Platform

Website - Chrome

Server Installation Method

Docker

Version

2.7.1 with merged Termix-SSH/Termix#1311 (dev-2.8.0)

CLI Installation Method

N/A

CLI Version

N/A

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have checked open issues and ensured this is not a duplicate

The Problem

Termix-SSH/Termix#1311 correctly normalizes Apple's private RFB 003.889 banner to RFB 003.008, but macOS then advertises security types 30,33,36,2,35. The compatibility proxy forwards that list unchanged, so guacd/libvncclient still selects Apple Remote Desktop authentication (30) before classic VNC password authentication (2). With a dedicated VNC viewer password and no username, the VNC child exits and the UI remains on “Connecting to VNC session...”.

This is the unresolved security-negotiation portion already documented in #1015. The new regression detail is that the merged banner proxy in Termix-SSH/Termix#1311 provides a place where Termix can safely constrain the advertised list, but currently does not do so.

A verified follow-up fix is available in Termix-SSH/Termix#1313. It filters the Apple security list to classic VNC authentication (type 2) only when type 2 is actually offered, while preserving standard RFB servers and Apple servers without type 2.

How to Reproduce

1. Run the Docker deployment with the dev-2.8.0 code containing Termix-SSH/Termix#1311 and guacd 1.6.0.
2. Configure a macOS Screen Sharing target with “VNC viewers may control screen with password” enabled.
3. Configure the Termix VNC connection with no username and the dedicated VNC password.
4. Connect through the web client.
5. Observe that the compatibility proxy is established but guacd selects/fails on Apple security type 30, or the UI remains stuck connecting.

Expected Behavior

When macOS offers classic VNC password authentication (type 2) for a username-less connection, the compatibility proxy should advertise only type 2 to guacd and allow the session to complete.

Actual Behavior

The banner is normalized, but the original list 30,33,36,2,35 is forwarded. libvncclient chooses type 30 and the connection does not complete.

Verification of Proposed Fix

Termix-SSH/Termix#1313 was tested with:

• Three proxy regression tests, including fragmented Apple negotiation and standard-server pass-through.
• ESLint and repository-wide TypeScript type checking.
• A production Docker build.
• A real end-to-end path: Termix web client → guacd 1.6.0 → compatibility proxy → macOS Screen Sharing. Authentication completed and the actual macOS lock screen rendered in the browser.

Additional Context

• Original related report: #1015
• Earlier regression report closed by #1311: #1206
• Incomplete merged fix: Termix-SSH/Termix#1311
• Verified follow-up PR: Termix-SSH/Termix#1313

Start with the compatibility-proxy changes and three regression tests described in Termix-SSH/Termix#1313, then review the Apple security negotiation path. Run the proxy tests, ESLint, TypeScript checks, and Docker build. Done means the standard-server pass-through remains intact and a username-less macOS VNC session authenticates through guacd and renders in the browser.