Add support for subscription connectionParams in GraphiQL

[Glockenbeat]

This PR adds the ability to pass connectionParams to the GraphiQL options in the GraphiQL plugins (solved #452).

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

[apollo-cla]

@Glockenbeat: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[DxCx]

LGTM but i think we need a better naming, at least adding websocket before so it will be
websocketConnectionParams

[Glockenbeat]

Would be possible of course, however I tried to stick to the naming which is used for the SubscriptionServer onConnect() method in the authentication example. Should we change it anyways?

[Glockenbeat]

Updated the naming as proposed, so it's "websocketConnectionParams" now.

[Stradivario]

Thank you guys! I was trying to implement some logic with cookies passed from the server.When the authorization header from the first graphiql request was passed to the client on second request for subscription cookies are passed trough socket and then the server verifies the token again.

Waiting for this to be merged :)

[rdickert]

I came to suggest this very thing and found it almost done. Awesome!

I have one possible change: Perhaps the item passed to websocketConnectionParams already be stringified rather than stringifying it at the destination. I was setting up some code:

  websocketConnectionParams: {
    authToken: localStorage.getItem('AUTH_TOKEN'),
  },

which is what we use on the client, but since I'm setting this up on the server, localStorage is undefined, and it throws an error. It needs to run this code on the client, so I probably have to be able to pass a string rather than actual objects so I can run this code in the right environment. i.e.,

  websocketConnectionParams: `{
    authToken: localStorage.getItem('AUTH_TOKEN'),
  }`,

We already do this with passHeader.

[martijnwalraven]

@Glockenbeat @DxCx: What do you think of @rdickert's proposal?

[Glockenbeat]

I like the idea of being able to use data from the client rather than setting it in the GraphiQL connection settings on the server. Something like that is definitely needed.

Personally I don't really like how the values are passed as a string as they are implicitly executed on the client, but since that is already implemented in the same way for passHeader it should be fine to use here as well.

[Glockenbeat]

Would it be possible to merge this PR and iterate on it afterwards? So far the discussion seems to be a bit stuck but I think this could be helpful for some people to work with connectionParams and websockets, even when there might be better implementations in the long run.

[martijnwalraven]

@Glockenbeat: I'd be happy to merge this if other people agree. @DxCx? @rdickert?

[stubailo]

Yeah let's do it!

[mjgallag]

Is there any way to pass an auth token from local storage with websocketConnectionParams as passHeader allows?