Feature: Equivalent to GraphiQL passHeader

[eric-burel]

This issue pertains to the following package(s):

• [ ] GraphQL Playground - Electron App
• [ ] GraphQL Playground HTML
• [X] GraphQL Playground
• [ ] GraphQL Playground Express Middleware
• [ ] GraphQL Playground Hapi Middleware
• [ ] GraphQL Playground Koa Middleware
• [ ] GraphQL Playground Lambda Middleware

What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?

1.7

Hi, I am updating the Vulcan.js framework (see https://github.com/VulcanJS/Vulcan/pull/2094), which is based on Meteor. The auth token is stored in localStorage['Meteor.loginToken']. In Apollo Server with GraphiQL, we had an hacky passHeader config, that could tolerate a string like "'Authorization': localStorage['Meteor.loginToken']". See https://github.com/apollographql/apollo-server/issues/299. Dirty but did the job.

Note that I am using apollo-server. My idea would be to allow a global header props (as requested in #510), and maybe allow people to make them a function of window. This way you could write:

{ 
  "endpoint": '/...', 
  "headers": (window) => ({ Authorization: window.localStorage['Meteor.loginToken'] })
}

It make sense imo to allow dynamic header configuration, because that's a common way to consume the api client side. Maybe my solution does not make sense though or could be replaced by smth more robust like cookies, I'd be glad to get feedback on this idea.

[eric-burel]

I am trying to understand how it could be implemented:

• You can't really pass a function as a header, because it needs to be serializable, since Playground is configured by Apollo server and props are passed through the wire.
• In this case, a possible solution would be to add a new option to tabs. I think of something like this: headersFromStorage: { localStorage: { "Authorization": "Bearer {Meteor.loginToken}", sessionStorage: { ... } }. Syntax seems a bit heavy but since many app rely on auth from a localStorage token, I think we can accept to make the config a bit more complex.
• To implement this, we would need to modify the INJECT_HEADERS action (or the Playground component that is responsible for triggering it). We would need to read the headersFromStorage object, and for each header key, parse the value to find the token key, fetch the token, and inject it in the headers, to eventually get Authorization: "Bearer ABCDEF" where ABCEDF === localStorage['Meteor.loginToken']

Another possibility would be to provide the function that generate headers as a string and then to run eval: since the config comes from the server, it's trusted code? But maybe that raises security issues I don't expect.

Am I on the right track? I'm feeling that the feature is not so difficult to implement and could help, but it's API is hard to define correctly.

[eric-burel]

Hi guys, just for documentation, the makers of Pup seems to have the same issue according to their doc: https://cleverbeagle.com/pup/v2/graphql/graphql-playground

It will be nice to support this feature or any similar kind of token based authentication, I'd be glad to give a hand on this.

[dinvlad]

Hi folks, it would be nice if this approach also allowed passing async functions - for example, I'd like to be able to refresh bearer token (if it's close to expiration) before assigning it to Authorization header. This check would happen on every request.