Field visibility based on user role

[ooga]

@ooga, any experience to work with GraphqlFieldVisibility to hide fields base on the user roles in reactive context? SchemaDirectiveWiring can change the field definition, but cannot hide it from Introspection call as the "GraphqlFiledVisbility" dose.

Originally posted by @jinwg in #437 (comment)

[ooga]

@jinwg Not at the moment but it's a feature that I will have to add.

we can add our progress in this discussion

[setchy]

@ooga, any experience to work with GraphqlFieldVisibility to hide fields base on the user roles in reactive context? SchemaDirectiveWiring can change the field definition, but cannot hide it from Introspection call as the "GraphqlFiledVisbility" dose.

Originally posted by @jinwg in #437 (comment)

I have a working solution for this using GraphQLFieldVisibility, a custom set of directives we've built for authorization, and Spring Security libraries for managing the JWT tokens

[setchy]

I used Blocked Fields as a starting point as documented on the field visibility documentation site

It mostly involved changing the block method to make use of information/context that would determine if an authenticated client could or could not see a given field/type

[jinwg]

the issue i am facing now is how to get the authentication from reactive context in the GraphqlFieldVisibility implementation when building the visibility rule base on user's roles?

[jinwg]

it looks below introspection class is not able to allow us to passed into the context :(

private static final DataFetcher inputFieldsFetcher = environment -> {
    Object type = environment.getSource();
    if (type instanceof GraphQLInputObjectType) {
        GraphqlFieldVisibility fieldVisibility = environment
                .getGraphQLSchema()
                .getFieldVisibility();
        return fieldVisibility.getFieldDefinitions((GraphQLInputObjectType) type);
    }
    return null;
};

[jinwg]

find this thread https://spectrum.chat/graphql-java/general/blocking-introspection-conditionally~1cb1be0f-1080-4ebf-a3dd-29dd02f3758f.

i am thinking to provide my own GraphQLSpringWebfluxInvocationInputFactory, there at least i can access the serverWebExchange object and also can trasform the scheme to get better performance? dose that sound a right direction?

[jinwg]

I finally make it work by providing a customized GraphQLSpringWebfluxInvocationInputFactory. also apply above suggest to transform scheme. i think possible a new context aware GraphqlFieldVisibility interface will be more generic solution here.

		var graphqlContext = this.getContextBuilderSupplier().get().build(serverWebExchange);
		if (graphqlContext instanceof AuthenticationContextAware context) {
			var scheme = this.getSchemaProviderSupplier().get().getSchema();
			var codeRegistry = scheme.getCodeRegistry()
					.transform(builder -> builder.fieldVisibility(new CustomFieldVisibility(context.getAuthentication())));
			scheme = scheme.transform(builder -> builder.codeRegistry(codeRegistry));
			return new GraphQLSingleInvocationInput(graphQLRequest, scheme, graphqlContext,
					this.getRootObjectBuilderSupplier().get().build(serverWebExchange));
		}
		return super.create(graphQLRequest, serverWebExchange);
	}```