Add ability to pass payload for GQL_CONNECTION_INIT message type

[varahash]

As described in appolo spec https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md#gql_connection_init
we can use optional 'payload' parameter for GQL_CONNECTION_INIT message type.

My reasoning here, is that I want put authorization token into connection init message.

[oliemansm]

@varahash What kind of solution do you have in mind, so how would you want to use that payload? It's passed in already, but currently we only send a response.

[varahash]

We need ability to handle payload from CONNECTION_INIT message to setup connection context.

For example:

• client sends message: {"type": "CONNECTION_INIT", "payload": { "authorization": "Bearer ..." }}
• server retrieves "authorization" field from message payload and tries to authenticate user. If authentication was success, server saves user authentication to connection context and responds to client with "CONNECTION_ACK" message. If authentication fails then server response with "CONNECTION_ERROR" message.
• once client receive "CONNECTION_ACK" he can start new subscription by sending "START" message.
• when server receive "START" message, it creates new subscription, but it also have access to connection context where current authenticated user is stored.

[oliemansm]

@varahash
Take a look at PR #111 please. This provides the API now that you can use to provide your own implementation of authentication. I've added a description in the PR explaining the approach.

[varahash]

Yeah, it solves the issue, but one thing is missing. If we throw exception in ApolloSubscriptionConnectionListener.onConnect() method, then you should catch this exception and put it as payload of "CONNECTION_ERROR" message.

[varahash]

From your last commit see that you returns Throwable.getMessage() as payload for "CONNECTION_ERROR" message, but this is not enough. I need ability to add additional fields to that payload. In particular, I want to return following payload: {"code":"my_code", "message":"same description"}.

The easiest way to achieve this, is just pass Throwable as payload for "CONNECTION_ERROR" message. In this case user will be responsible to configure Jackson annotation on his custom exception to chose which fields will be serialized into JSON.

[oliemansm]

In that case I'll let it throw a SubscriptionException that you can construct with an Object payload which will be used as payload in the error message. Think that's a bit cleaner. And you could still pass in your custom exception as the payload Object if you really want to.

[varahash]

Yeah, that make sense.