Graphene: Limiting introspection

Created on 16 Aug 2017  路  11Comments  路  Source: graphql-python/graphene

Hi there!

I was looking into how to implement something similar to the functionality that Warden gives to graphql-ruby. Based on the context at execution time, I would like to hide certain schema elements from the user in queries, mutations, and introspection queries.

Because users and their access can vary a lot in my app, I don't want to generate a separate Schema for each type of access.

What would be the suggested/best way to go about this? Should it be done in a custom Executor class? Maybe overriding GraphQLSchema, the type definitions, and TypeMap in graphql-python to take in masks could also work.

Also, would a feature like this be on the roadmap for this framework?

Some additional discussion:

Thanks!

question wontfix

Most helpful comment

this is easily implemented as a middleware (easy for at least completley turning off introspection, i want to work on it more to possibly allow limited fields to be introspected) but for now i have a working graphene middleware here: https://github.com/jstacoder/graphene-disable-introspection-middleware

All 11 comments

This is also something that we'd like to see implemented. We've been using Graphene in production internally for a couple months now and the experience has been great so far. However, to allow us to open our API to 3rd parties, we need to be able to limit the introspection queries based on the context at execution time.

@syrusakbary, would you be able to provide some suggestions on how this could be implemented? I'd love to help build this feature, but I'm not sure where to start.

It is kind of useful because in our case, we need user_id to resolve user

it would be better if frontend team only see user in introspection

Same issue with @pobed2
Don't know how to solve it yet.

Gentle bump for this? With Graphene-Django I've made middleware to change access rights depending on whether the user is authenticated (see graphql-python/graphene-django#345), but the whole schema can still be introspected which is not ideal.

this is easily implemented as a middleware (easy for at least completley turning off introspection, i want to work on it more to possibly allow limited fields to be introspected) but for now i have a working graphene middleware here: https://github.com/jstacoder/graphene-disable-introspection-middleware

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Are there any updates on this functionality?

Here's the doc to the webonyx/graphql-php implementation.

For blocking introspection in production, the middleware solution @jstacoder described works fine
(and you can block introspection based on context - request parameters, headers, user etc. as the middleware gets the context via info.context)

However, I'm not what is the use case for only partially blocking the schema. It seems like a not very "GraphQL-y" solution.
I mean, if you look at Relay\Apollo as the main clients for GraphQL m- they need to know the schema at build time so you can't use such trickery...

You can use a middleware to determine permission to query certain values based on context but I'm not sure hiding values entirely from the scheme is something you want to do...

@ekampf
we have a graphql api for our ios app to consume, it is not public facing, so this helps us by allowing us to have introspection in development (so we get highlighting and tab completion) but to restrict it in production, where it would only describe our api to people who dont need to know it.

I found this helpful disabling graphene introspection

Was this page helpful?
0 / 5 - 0 ratings