Open eric-burel opened 6 years ago
I am trying to understand how it could be implemented:
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.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.
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.
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.
This issue pertains to the following package(s):
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 hackypassHeader
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 ofwindow
. This way you could write: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.