New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to submit headers on handshake (session cookie etc). #7
Comments
Hi @perholmes Did you find any solution to this? |
Sort of, well, worked around it. We only care about this in the development environment, so we made the webserver code to accept the token in the URL, but only in the development environment. The WebSocket terminates in a Go container where we go through the upgrade from HTTP to WebSocket. This is where we normally pick up the session token header, which is sent by the browser when the WebSocket is called from the browser. So this is where we also listen to a ?sessionToken=1234567890, but only in the development environment. That allows us to test WebSocket connections. As I understand, this is actually a physical limitation that WebSocket King can't do much about. So we tested several other clients. PostMan for example has a more elaborate WebSocket tester where you can also set headers. Unfortunately, we were never able to get PostMan or other local WebSocket clients to connect to the local Docker cluster. Some sort of routing or IPv4/IPv6 issue, but we could never resolve it. So we're testing with WebSocket King and URL session tokens for connections in the dev environment. |
@perholmes: Timely... I just hit this issue myself. I had the same experience with Postman which is why I ended up with Web Socket King. I am using a Java Quarkus endpoint. Your solution is what I was imagining I might need to do. Thanks for the verification of a way forward. :-) |
how i can connect to django channels to websocketking |
Hi,
It's common to authenticate using session cookies during the HTTP handshake, but I can't find any way to do this in WebsocketKing.
Am I just not finding the feature, or doesn't it exist? If so, it's a pity that WebsocketKing can't be used for authenticated websockets.
The text was updated successfully, but these errors were encountered: