Hide parts of schema

[Sam-Kruglov]

Hi, just highlighting for consideration, I think it would be useful to hide certain parts (fields, types) of the schema based on authorization. There are some uses of it if you google "graphql hide fields". I personally haven't used this feature.

[MiguelAngelLV]

You can create a SchemaMapping for the fields and return null / empty if the user don't have permission.

[rstoyanchev]

Thanks for raising this. It seems quite related to #116 although it's not entirely clear whether the same directives would be used for this as well or whether hiding would have to be expressed differently. More generally if defining authorization should result in field errors or those errors simply being hidden. /cc @rwinch

It's also not clear to me what should be hidden? We have the schema printing endpoint that returns the full schema. There is GraphQL introspection that could be used. There are GraphQL responses as well. Anything else? I imagine any hiding mechanism should cover all of those or otherwise it's not really hiding it.

Any further details around the actual use case and needs would be helpful to hear and keep in mind. Some examples from real world APIs could also be worth checking (GitHub's comes to mind as having such a feature).

[Sam-Kruglov]

I imagine the usecase is to have certain fields/types appear as if they don’t exist in the schema for the user who doesn’t have permission to see them. Must not disclose the permission requirements to the user.

[bclozel]

It sounds like this should be enforced at the schema printing level and introspection level at least. When it comes to responses themselves, nulling out a field that's not marked as nullable in the schema will cause issues.

Back to the use case itself, it seems that this can be useful for:

• hiding data and features to users that lack privileges
• performing feature toggle, schema previews or schema versioning

GraphQL Java seems to support that through field visbility and other frameworks do too.

[Jamel-jun]

Are there any relevant conclusions available? It seems that this feature would be helpful to me.

[rstoyanchev]

@Jamel-jun and others, describing concrete use cases would help to move forward with this issue.

In addition, have you tried the GraphqlFieldVisibility hook in GraphQL Java? We do know it is not suited for a reactive or async security service (see #284), but besides that, does it work as expected on Spring MVC or are there more limitations, and what do you imagine we can do to make using this easier?

[bclozel]

We discussed this issue today and we don't see what value Spring for GraphQL can add, given the support already present in graphql-java.

We can reopen this issue if we get a better picture of what should be done.