Modify an existing [url removed, login to view] XMPP connection manager with XMPP over WebSocket support to do the following:
1. Accept client connections _only_ over secure WebSocket
2. Perform extended validation of WebSocket handshakes using Cookie: and Origin: headers based on rules held in a MySQL database (note, on successful validation some additional data must be persistently stored in the connection data-structure as it will be used later)
3. Distinguish between client originated traffic for local XMPP domains and remote XMPP domains based on rules held in a MySQL database and the additional data stored in the connection data-structure by analysing the JID of the originator of the XMPP message.
4. Perform extended validation of XMPP requests received from the client (slightly different validation for local and remote domains) based on rules held in a MySQL database and the additional data stored in the connection data-structure.
5. Route remote traffic to the remote XMPP server by IP address, hostname (multiple A records may be used for resiliency), or DNS SRV to the domain from the JID of the XMPP message originator. Remote connections must be over mutual TLS with certificates verified by a trusted CA.
6. Accept traffic for XMPP clients from the remote XMPP servers over the established TLS connections (note that all TLS connections are created from the connection manager to the server which means these connections must be maintained by the connection manager as long as the relevant clients are connected).
7. Local traffic will be sent to and received from a local eJabberd instance over TCP.
8. All traffic through the connection manager is client related. There is no requirement for federation between XMPP servers through the connection manager.
The connection manager is: [url removed, login to view]
Resiliency for the connection manager will be achieved by deploying multiple instances.
Extended validation rules and data-structures to follow later.