Sanitize field values or input field values

[donbeave]

Hello!

First of all, thank you for developing such an amazing engine. It's beautiful work and a very good innovation that will move the Java ecosystem forward.

I found one issue, but not sure if is it by design, or it's lack of my knowledge.

I have such DSL:

directive @stripHtml on ARGUMENT_DEFINITION | INPUT_FIELD_DEFINITION

type Query {
  searchProfile(contains: String! @stripHtml, limit: Int): [Profile!]!
}

type Mutation {
  signUp(input: SignUpInput!): SignUpPayload!
}

input SignUpInput {
  username: String! @stripHtml
  password: String!
  firstName: String!
  lastName: String!
}

type Profile {
  username: String!
  fullName: String!
}

I would like to use @stripHtml directive to sanitize values, like in searchProfile the contains argument must remove all HTML code from the value, and the same for the field username in SignUpInput.

Looks like the current version of graphql-java allows doing so by using custom data fetchers only, and sanitizing values customly inside the data fetcher. But this isn't an easy way, as it requires going through all mapped entities and checking does it inside a list of fields or arguments annotated with this directive.

But I'm looking for an API that allows doing so somehow before, and with the sanitized results already in DataFetchingEnvironment class, like this method will return sanitized values already:

graphql-java/src/main/java/graphql/schema/DataFetchingEnvironment.java

Line 47 in 477d9a0

Map<String, Object> getArguments();

.

And in terms of SignUpInput, let's imagine I'm using a plain Java DTO class for that input, and the sanitized value will be passed to the method setUsername(String username).

@andimarek @bbakerman What do you think, is it possible to add some processor API that will allow us to post-process the value?

[bbakerman]

I understand what you want and we have considered a kind of pre-validation callback before but every time we considered it - we realised two things

• its hard to know what things needs to be validated / changed in the layer
• we already have a callback layer called the DataFetcher

So really we aim for the data fetcher to be the callback layer - graphql-java is complicated enough without need more sub specialised callbacks

There are a couple of things you can do here.

If you are building your schema from SDL (and it looks like you do) then you can use graphql.schema.idl.SchemaDirectiveWiring to wire in new data fetchers that do custom things first and the call the old data fetcher

Take a look at https://github.com/graphql-java/graphql-java-extended-validation which uses this.

directive @Size(min : Int = 0, max : Int = 2147483647, message : String = "graphql.validation.Size.message")
                        on ARGUMENT_DEFINITION | INPUT_FIELD_DEFINITION

    input Application {
        name : String @Size(min : 3, max : 100)
    }

    type Query {
        hired (applications : [Application!] @Size(max : 10)) : [Boolean]
    }

If you squint it a bit like yours - except it stops on validation errors - yours wants to change the argument values

It uses directives on fields as validation rules and introduces a wrapper data fetcher that enforces the rules. In this case it only validates. It does not modify the input args but it could

Imagine this SchemaDirectiveWiring

    @Override
    public GraphQLFieldDefinition onField(SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition> env) {
        GraphQLFieldsContainer fieldsContainer = env.getFieldsContainer();
        GraphQLFieldDefinition fieldDefinition = env.getFieldDefinition();

        // you need to check the applied directives on the field args and their types to see
        // if you custom sanitizing applies - if not leave it alone
        // you will need to descend into the types of the arguments
        if (! hasYourDirectives(fieldDefinition, fieldDefinition.getArguments())) {
            return  fieldDefinition;
        }

        final DataFetcher<?> originalDF = env.getCodeRegistry().getDataFetcher(fieldsContainer, fieldDefinition);
        final DataFetcher<?> newDF = originalEnv -> {
            Map<String, Object> originalArguments = originalEnv.getArguments();
            Map<String, Object> newArguments = sanitizeArgs(originalEnv, originalArguments);

            DataFetchingEnvironment newEnv = DataFetchingEnvironmentImpl.newDataFetchingEnvironment(originalEnv).arguments(newArguments).build();
            return originalDF.get(newEnv);
        };

        env.getCodeRegistry().dataFetcher(fieldsContainer, fieldDefinition, newDF);

        return fieldDefinition;
    }

This needs to do 2 things - look at the field and its arguments the type of the arguments for your custom directives - if they are present then continue

Then this creates a new DataFetcher for the field whose job it is to sanitize the arguments and create a new DFE with those args.

It then calls the original data fetcher who is none the wiser that code aspects have been wired in.

This schema wiring happens are schema build time (once) and so the originally wired data fetcher is still called - but with different values

Let me know if this helps or you have more questions.

[bbakerman]

ps this is more a discussion than an bug so I am moving it to discussions

[paullarionov]

Hello Brad @bbakerman and Alexey @donbeave,

Thank you both for great question and brilliant answer.

I tried SchemaDirectiveWiring solution above and find out that onField is used for output types, but for input types (like Application in your example) there will be called other method onInputObjectField:

    @Override
    public GraphQLInputObjectField onInputObjectField(SchemaDirectiveWiringEnvironment<GraphQLInputObjectField> env) {
        GraphQLFieldsContainer fieldsContainer = env.getFieldsContainer(); // this is null
        GraphQLFieldDefinition fieldDefinition = env.getFieldDefinition(); // this is null
        GraphQLInputObjectField inputObjectField = env.getElement();

        if (!hasYourDirectives(inputObjectField)) {
            return inputObjectField;
        }

        // there is null in fieldsContainer and fieldDefinition
        // that is why we cannot override DataFetcher in CodeRegistry
        
        // final DataFetcher<?> originalDF = env.getCodeRegistry().getDataFetcher(fieldsContainer, fieldDefinition);
        // final DataFetcher<?> newDF = originalEnv -> {
        //     Map<String, Object> originalArguments = originalEnv.getArguments();
        //     Map<String, Object> newArguments = sanitizeArgs(originalEnv, originalArguments);
        //     DataFetchingEnvironment newEnv = DataFetchingEnvironmentImpl.newDataFetchingEnvironment(originalEnv).arguments(newArguments).build();
        //     return originalDF.get(newEnv);
        // };
        // env.getCodeRegistry().dataFetcher(fieldsContainer, fieldDefinition, newDF);

        return inputObjectField;
    }

For input objects there is no GraphQLFieldsContainer and GraphQLFieldDefinition, that is why it is not possible to override DataFetcher in DataFetchingEnvironment. I have concern that data fetchers are simply not applicable for input objects.

Guys, do you have some ideas?

[bbakerman]

The link above leads to a PR and that PR is merged - its in the graphql code base since Dec 3, 2022

The PR has a test and the test above talks about it in a general sense.

[AVLOUIS99]

Thanks for the quick reply and thanks for the extension which I had been looking for a while!

I saw that and tried to familiarize myself with it, but my problem goes back to the question of paullarionov, because unfortunately I have exactly the same problem and had hoped the thread could help me with it. Thanks in advance!

I am relatively new to graphql and would appreciate some information.

[paullarionov]

Hi @AVLOUIS99. Sure, here is small code example of a directive, which traverses input objects:

import graphql.schema.DataFetcher;
import graphql.schema.DataFetchingEnvironment;
import graphql.schema.GraphQLFieldDefinition;
import graphql.schema.GraphQLFieldsContainer;
import graphql.schema.idl.SchemaDirectiveWiring;
import graphql.schema.idl.SchemaDirectiveWiringEnvironment;

@Component
public class YourDirectiveWiring implements SchemaDirectiveWiring {

    @Autowired YourValueTraverser yourValueTraverser;

    @Override
    public GraphQLFieldDefinition onField(SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition> env) {
        GraphQLFieldsContainer fieldsContainer = env.getFieldsContainer();
        GraphQLFieldDefinition fieldDefinition = env.getFieldDefinition();

        final DataFetcher<?> originalDF = env.getCodeRegistry().getDataFetcher(fieldsContainer, fieldDefinition);
        final DataFetcher<?> newDF = originalEnv -> {
            DataFetchingEnvironment newEnv = ValueTraverser.visitPreOrder(originalEnv, yourValueTraverser);
            return originalDF.get(newEnv);
        };

        env.getCodeRegistry().dataFetcher(fieldsContainer, fieldDefinition, newDF);

        return fieldDefinition;
    }

}

Where YourValueVisitor is the implementation of ValueTraverser (https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/analysis/values/ValueTraverser.java)

[AVLOUIS99]

Hi @paullarionov thanks for the reply!
Isn't the onField method only for field_definition directives?

input typeFilter {
    state: Int
    opening: String @uppercase
}

directive @uppercase on INPUT_FIELD_DEFINITION

This is the last problem of understanding that I still have in this matter.

[AVLOUIS99]

Got it! Thank you guys! 👍