Graphql-playground: Q: How can I pass the Authorization header when fetching my schema?

[barbosa]

Hi guys.

Thanks for open sourcing this amazing tool.

I'm using the Mac client and I'm trying to find a way to set the Authorization header to fetch my GraphQL schema by clicking that Reload Schema button at the top right corner.

Other requests work fine, since I can set the header for them. But since my schema is also under this auth layer, I can't fetch it by using that feature.

Thank you!

[batjko]

Yea that doesn't seem to work.

In my case, we have our GraphQL server behind an authorization middleware that requires the Auth header or returns a "Token required" error.
So in Playground, it now always initially shows the Token error in the right pane (despite me having added the header already), until I press play.
And, as you say, the schema (and the resulting autocomplete etc) won't work at all.

[tlvenn]

I am wondering if it's something that shouldn't be better handled / fixed on the server...

It seems fairly reasonable to expect that the introspection query in dev mode would not need any authentification and then it would allow Playground to fetch the schema properly.

I get the feeling that the authorization middleware you are using happens to match on the introspection query and try to enforce that the request is authenticated while most probably it should simply do nothing in this case.

In prod mode, most probably you either allow introspection queries if you run a public API or you simply turn it off.

Is there a valid use case where introspection query should not be public ?

[batjko]

It seems fairly reasonable to expect that the introspection query in dev mode would not need any authentification

Actually, not all APIs are supposed to be exposed freely to the interwebz. Ours is used by our own apps only and so requires those apps to send an Auth header with each request or it... shall not pass.

Edit: In fact, thinking about it, most APIs in the world are probably private. All client apps companies put out use a back-end API, and only a minority of them go through the trouble of making that public, naturally.

I get the feeling that the authorization middleware you are using happens to match on the introspection query and try to enforce that the request is authenticated while most probably it should simply do nothing in this case.

As above, we're not matching on any particular query. It's very simple: We use an Express server that has the Graphql endpoint defined, but above that definition, we basically say: only let the request (any request to /graphql) through if that auth header is present and validated.

In prod mode, most probably you either allow introspection queries if you run a public API or you simply turn it off.

The latter.

But that doesn't mean that we (the developers) don't still want to use it for development and debugging purposes...

[tlvenn]

I totally understand your use case but then if introspection is turned off in prod, most likely you can safely turn it on without any auth in dev mode knowing it's only available on your intranet at most and worse comes to worse, we are only talking about the schema itself.

If you have a public facing staging env, it should behave like in prod and therefore introspection should be turned off.

It should be fairly simple to modify your express middleware to check in dev if the query is an introspection query (it will start with __schema) and pass through if it's the case.

The thing is I dont really see how this can be solved within Playground.

[batjko]

To be honest, I don't see why it would be preferable to have users change their code for this tool, as opposed to making the tool behave consistently (because support for headers is already in there, just not used for the introspection).

It's both simpler and more intuitive.

The thing is I dont really see how this can be solved within Playground.

Why not? It does it for on-demand requests already.

[eschlenz]

What @batjko is asking for is pretty much the only thing I see lacking in this tool so far. I can see the argument for relaxing authentication on a local network, but it still seems like the tool should support some way of passing authentication for the schema request. Can you explain @tlvenn why you don't believe this can be achieved in the Playground app? Maybe the community has some ideas.

[tlvenn]

Well it can definitely be done, I shouldn't have said this cant be done and it's not that complex either, it's just that I feel the burden of this should be on the server side because the general expectation is that the schema should be publicly available, at the very least in dev as to help developers and the tooling ecosystem.

For me, and that maybe just me, that is kinda the contract and as a result, none of the graphiql tools around, support auth for the introspection query, it's not just about this particular graphiql tool.

If you happen to have some auth / permission middleware, I would argue it's your job to make sure you can still serve the introspection query without any auth whatsoever in dev mode. And that is actually pretty easy to do.

[batjko]

because the general expectation is that the schema should be publicly available

I'm sorry but that's simply unrealistic. As I mentioned above, most APIs in the world are private. Unless your job is to work solely on public APIs, which is rare, most client apps in the wild will access their back-end API privately. Opening up your internal API to the public is usually neither wanted nor financially feasible.

I don't want to assume too much, but your perception may be skewed if all you work with every day are public APIs.

If you happen to have some auth / permission middleware, I would argue it's your job to make sure you can still serve the introspection query without any auth whatsoever in dev mode.

I think the cost-benefit here is very obviously the other way around, though: This playground tool already has the capability to send a header with the request (lower left corner).
The only thing that's missing (and inconsistent) is that this header isn't used by the app when it queries for the introspection schema. I haven't seen the exact code, but that should be fairly straight forward.
And there is clearly a demand for this, as well.

[tlvenn]

I'm sorry but that's simply unrealistic. As I mentioned above, most APIs in the world are private. Unless your job is to work solely on public APIs, which is rare, most client apps in the wild will access their back-end API privately. Opening up your internal API to the public is usually neither wanted nor financially feasible.

I am talking in dev mode here @batjko. I don't work on a public api either and introspection is turned off in prod and staging. However I make sure it's freely available to the dev team in dev mode so tooling can leverage it as well, be it graphiql, graphiql-workspace, graphiql-playground, relay etc...

I think the cost-benefit here is very obviously the other way around, though: This playground tool already has the capability to send a header with the request (lower left corner).

You have to keep in mind there is a huge eco system around graphql on the client side and it's definitely easier to fix it in one place (the server) and have all the tools just work than the other way around imho.

[kbrandwijk]

I really don't see why this is becoming such a big deal in the discussion. You can access an endpoint that is protected by passing an Authorization header with the query/mutation. You should be able to do the same for getting the schema, which is nothing more than executing the introspection query against that same endpoint.

@tlvenn With graphiql, you can add the header to the fetcher when self-hosting, with graphiql-workspace the header you specify at the top is also used for the introspection query, with get-graphql-schema you can set the header at the command line, so it's not like every tool out there ignores protected endpoints.

[tlvenn]

Hi @kbrandwijk , I guess I was trying to be practical and it escalated quickly from there. Playground could probably follow the same strategy as graphiql-workspace.

[timsuchanek]

In the latest version of the playground we're sending the auth headers as @kbrandwijk with the introspection query. You have to do one reload, which is ugly, but having a nicer solution for that would mean inserting the auth information before launching the playground.
We might do that in the future, but I think this solution is fine for now.