You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So this already came up some times before: #649 & #405. But it never got anywhere
So I'm here to see if there is interest in getting this in even or that it's out of scope.
I'm really impressed by how GraphQL-Ruby has implemented this.
With GraphQL-Ruby, it’s possible to hide parts of your schema from some users. This isn’t exactly part of the GraphQL spec, but it’s roughly within the bounds of the spec.
They list some great arguments about why this is useful:
Here are some reasons you might want to hide parts of your schema:
You don’t want non-admin users to know about administration functions of the schema.
You’re developing a new feature and want to make a gradual release to only a few users first.
This is in part a security through obscurity functionality BUT it's also a really functional feature to be able to have feature switches and test out new parts of the schema in production without it being part of the public schema immediately.
That last part (feature flagging, incremental rollout) is what interests me most about this feature (see for example how GitHub is using it to hide their discussions API behind a feature flag.
I have been browsing around and I think a possible (from the user perspective) implementation could look something like this:
$userType = new ObjectType([
'name' => 'User',
'description' => 'Our blog visitor',
'fields' => [
'firstName' => [
'type' => Type::string(),
'description' => 'User first name'
],
'email' => Type::string(),
'internalId' => [
'type' => Type::string(),
'description' => 'Example field that could be hidden'
+ 'visible' => function ($context): bool { /.../ },
],
],
+ 'visible' => function ($context): bool { /.../ },
]);
GraphQL-Ruby implements the following rules for the visible callback result:
These methods are called with the query context, based on the hash you pass as context:. If the method returns false, then that member of the schema will be treated as though it doesn’t exist for the entirety of the query. That is:
In introspection, the member will not be included in the result
In normal queries, if a query references that member, it will return a validation error, since that member doesn’t exist
These rules would as far as I'm concerned also apply to graphql-php since they seem reasonable and go a little further than simply hiding them from the introspection, they basically remove them from the schema entirely so they also cannot be called.
I'm mainly here to see IF this is even something that would be considered for inclusion in graphql-php so please give me some feedback on the idea (which is a shameless copy of the GraphQL-Ruby implementation and not a original idea) so I know if I should be moving forward or that it won't be accepted at all 😄
The text was updated successfully, but these errors were encountered:
I think this is a useful addition and does not violate the specification.
It seems that only introspection will be affected at runtime and has to do a bit of extra work. Apart from that, there should be no negative effects from adding this.
Given the implementation is simple enough, i would be up for inclusion 👍
So this already came up some times before: #649 & #405. But it never got anywhere
So I'm here to see if there is interest in getting this in even or that it's out of scope.
I'm really impressed by how GraphQL-Ruby has implemented this.
They list some great arguments about why this is useful:
This is in part a security through obscurity functionality BUT it's also a really functional feature to be able to have feature switches and test out new parts of the schema in production without it being part of the public schema immediately.
That last part (feature flagging, incremental rollout) is what interests me most about this feature (see for example how GitHub is using it to hide their discussions API behind a feature flag.
I have been browsing around and I think a possible (from the user perspective) implementation could look something like this:
GraphQL-Ruby implements the following rules for the
visible
callback result:These rules would as far as I'm concerned also apply to graphql-php since they seem reasonable and go a little further than simply hiding them from the introspection, they basically remove them from the schema entirely so they also cannot be called.
For a bit more detail check out the excellent GraphQL-Ruby docs page: https://graphql-ruby.org/authorization/visibility.
I'm mainly here to see IF this is even something that would be considered for inclusion in graphql-php so please give me some feedback on the idea (which is a shameless copy of the GraphQL-Ruby implementation and not a original idea) so I know if I should be moving forward or that it won't be accepted at all 😄
The text was updated successfully, but these errors were encountered: