-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Equivalent to GraphiQL passHeader #849
Comments
I am trying to understand how it could be implemented:
Another possibility would be to provide the function that generate headers as a string and then to run 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 VulcanJS/Vulcan#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 apollographql/apollo-server#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.
The text was updated successfully, but these errors were encountered: