The client websocket port is still used for communication between client and server for transferring image stream and interactions.
In Backend mode the WebViewer server does not allow to start a session without prior authentication by a connected leading system's application server before. This way we implement our session based security feature. A firewall or proxy in front allowing connections for valid application servers only should secure the WebViewer's second websocket port. We do also recommend to operate a proxy for SSL off-loading in front of the WebViewer server (NGINX, Apache, IIS ...) in productive environments.
After connecting to second backend websocket port leading system sends a custom token used for authentication as one time key. On successful session authentication this token is consumed and the leading system receives an authentication succeeded event containing the client's id. This ClientId has to be send with all XML-API calls and events belonging to this session. Before sending first XML-API command like OpenFile wait for SessionReady event.
Leading system can list all active clients and terminate or transfer sessions.
WebViewer Backend mode is available for Full UI and embedded scenarios.
For full UI WebViewer client pass your custom token in the URL on starting new WebViewer browser tab or iframe. Other full UI client URL parameters (like open or compare) are not available any more.
Send all XML-API calls for controlling a WebViewer client session directly on the second websocket port with ClientId as session identifier.
Have a look at Backend Cockpit sample code in
vsweb-example-backend-cockpit.html/.js for details.
You can enable Backend mode and define Backend websocket port in "ViewStationWeb.ini"
Sending custom token used for authentication first. Then starting the session by passing same token. New session authenticated directly. Authentication succeeded event contains sessions id, client IP and consumed token for reference.
This option may be used for load balancing scenario with more than one WebViewer server. Load balancer can allocate the client to one of the WebViewer servers. This WebViewer server sends waiting session events to all backend application servers connected by backend websocket.
Starting a new session URL with custom token first. New session is waiting for authentication or will run into timeout.
WebViewer server sends event for waiting session containing token and client iP to backend application servers. Application server responsible for this client session will send same custom token for authentication. Session-is-started and authentication-succeeded events contain the client ID and consumed token for reference.
Subsequent events after successful authentication belonging to one session are just send to the authenticating application server.
Sessions can be transfered between application servers.
API calls and events
WebViewer server <-> leading systems applications server
After event SessionReady Received -> Send API calls to  open a new scene and update the scene or  just open a file
[1.1] Backend send NewScene (and some initial scene settings)
Sending your additional API calls and receive events (for e.g selection changes)