Pass handshake request up to connection handler

[adrianhopebailie]

I'd like to be able to use rsocket over WS and leverage the HTTP handshake for authentication of the client.

In the connection event on the WS server I get both the new socket and the incoming handshake request which allows me to, for example, authenticate the request by looking for an auth token in the headers.

Unfortunately the transport abstraction in rsocket-js means there is no way to pass this up from the transport to the server when a new DuplexConnection is published by the transport.

I haven't explored the details but it seems like mutual TLS could also be used to secure the TCP transport. In that case a similar issue arises of needing to pass the output of the auth on the transport up to the server with the DuplexConnection.

It seems like the place to do this is in the getRequestHandler: (socket, payload) callback as a third variable. To expose this from the transport it would need to be added as a new property on the DuplexConnection published by the transport.

If this sounds workable I can try and put a PR together

[adrianhopebailie]

related question in the forums: https://community.netifi.com/t/using-transport-layer-authentication/221/2

[adrianhopebailie]

FYI: After extensive research on this, it seems that many server libraries don't expect a WebSocket connection to be authenticated using headers (for example using a bearer token in the Authorization header).

The reason being that the most common client is a browser and the WS API in browsers doesn't allow for custom headers.

At least for now, if you want to authenticate an incoming WS connection during the handshake and not have to write an auth protocol into rsocket, the auth will likely need to be based on cookies or similar to handle browser based clients.

[OlegDokuka]

Hi @adrianhopebailie! I started an appropriate API change in the RSocket-Java which let you access to the incoming headers -> rsocket/rsocket-java#691

Feel free to leave the comment.

I'm planning to finish the work on the java side by the end of the week, so if it looks good, I'm going to adopt the same for JS version as well.

Regards,
Oleh

[OlegDokuka]

It seems that there is no way to make a "proper" WebSocket authentication using a non-cookies based solution. Alternatively, it is possible to use a different authentication mechanism and do that at the post handshake phase. For example, it is possible to send authentication during the rsocket protocol setup phase in a setupPayload metadata (please see -> https://github.com/rsocket/rsocket-js/blob/master/packages/rsocket-examples/src/CompositeMetadataExample.js#L51 and https://github.com/rsocket/rsocket-js/blob/master/packages/rsocket-examples/src/CompositeMetadataServerSideExample.js#L50).

@adrianhopebailie should we keep this ticket open?

[czymstef]

@OlegDokuka how would the cookie based authentication work? I'm trying to figure this out for quite some time now in the spring integration with no luck. I'm trying to use the authentication information available in the websocket handshake (mainly cookies in my case) to authorize requests to specific routes, see this Stackoverlow question.