Sync Gateway: Changes Feed over Websockets cannot support basic authentication by JS/web clients

Websockets is one of the supported options for data access over Sync Gateway REST endpoint.
https://docs.couchbase.com/sync-gateway/current/server-integration.html#changes-feed

However, JS clients cannot add authorization headers to WS requests as described
https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api
https://devcenter.heroku.com/articles/websocket-security#authentication-authorization

https://forums.couchbase.com/t/authentication-issue-with-websocket-using-syncgateway-public-rest-api-2-8/29288

This is a major gap in supporting web based apps who may want to use websockets over continuous HTTP for interacting with SGW.

The alternative to basic auth described in the links

• So, one pattern we’ve seen that seems to solve the WebSocket authentication problem well is a “ticket”-based authentication system. Broadly speaking, it works like this:
• When the client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization “ticket”.
• The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other sort of internal record keeping you might need.
• The server stores this ticket (i.e. in a database or cache), and also returns it to the client.
• The client opens the WebSocket connection, and sends along this “ticket” as part of an initial handshake.
• The server can then compare this ticket, check source IPs, verify that the ticket hasn’t been re-used and hasn’t expired, and do any other sort of permission checking. If all goes well, the WebSocket connection is now verified.

Early input from Adam:

It sounds like it would be similar to the previous approach for websocket _changes, where an initial handshake message is sent by clients prior to SG streaming changes the other way. We'd need to consider the security implications in a bit more detail.