第5课 GraphQL身份认证

在GraphQL（四）：GraphQL工程化实践中说到权限管理，是用 Instrumentation 来实现，这其实是很坑的，因为API和权限的关系需要自己实现，如果能够像spring注解一样，直接在定义API的时候就关联上相应的权限，然后在后端根据用户权限和API权限做判断，那么现有的spring的权限控制的逻辑都可以复用，并且要扩展更多需求也更优雅。说到底，根本上是期望能够有一种更便捷的方式拦截GraphQL的API。

Derectives

在GraphQL规范中有定义一个叫做Derectives的家伙

Directives provide a way to describe alternate runtime execution and type validation behavior in a GraphQL document.

乍一看，这不就是我们需要的功能吗？

然而，这个这么有用的功能GraphQL-Java在9.0版本才实现，实在是姗姗来迟啊。而如果是通过GraphQL-Java-Tools来使用GraphQL需要使用5.2.4以上的版本才能享受Derectives。

利用Derectives实现GraphQLAPI拦截

总共分成三个步骤：

1. 在schema中定义并使用Derectives

directive @role(roles : [Int!]!) on FIELD_DEFINITION

type Query{
  stages:[Stage!]! @role(roles : [101])
  subjects:[Subject!]!  @role(roles : [100]) @deprecated(reason:"is old value")
}

我们定义了一个叫做“role"的Derective，它带有一个Int的数组作为参数。当我们在API上使用Derective，通过不同的参数就可以区分不同的权限。

2. 实现Derective的拦截

class RoleDirective : SchemaDirectiveWiring {

    override fun onField(environment: SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition>?): GraphQLFieldDefinition {
        val targetRoles = environment!!.directive.getArgument("roles").value
        val field = environment!!.element
        val originalDataFetcher = field.dataFetcher

        val dataFetcher = DataFetcher {
            val user = AuthInfoHolder.authInfo.user
            val userRole= getUserRole(user)
            val requireRoles = targetRoles as List<Int>

            if (!requireRoles.contains(userRole)) {
                throw Exception("requireRoles")
            }
            originalDataFetcher.get(it)
        }

        return field.transform { it.dataFetcher(dataFetcher) }
    }
}

SchemaDirectiveWiring 是充当胶水的一个类，它将schema中的Derective和GraphQL引擎关联起来。

3. 将RoleDirective注入GraphQL引擎

如果是用GraphQL-Java-Tools，在构建SchemaParserBuilder时直接注入：

schemaParserBuilder.resolvers(resolvers!!)
       .directive("role", RoleDirective())
       .build()

如果没用GraphQL-Java-Tools呢？这就要做更多的事情了，在介绍原理时再来介绍这部分。

Derectives原理（基于GraphQl-JAVA-TOOLS 5.5.2）

在介绍Derectives原理前需要了解一个概念：DataFetcher。

GraphQL通过DataFetcher获取每一个字段的值，比如上面的stages、subjects，包括stage里面的子属性stageId、stageName等，都对应了一个DataFetcher。后续会专门写一篇文章来介绍DataFetcher，这里先简单了解。

回到上面第二步的代码：

class RoleDirective : SchemaDirectiveWiring {

    // 重写onField方法，拦截标记了Directive的API
    override fun onField(environment: SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition>?): GraphQLFieldDefinition {
        // 获取Directive中的参数值（类似于获取注解中的参数值）
        val targetRoles = environment!!.directive.getArgument("roles").value
        val field = environment!!.element

        // 获取原来的DataFetcher
        val originalDataFetcher = field.dataFetcher

        // 包装了原始DataFetcher的新的DataFetcher
        val dataFetcher = DataFetcher {
            val user = AuthInfoHolder.authInfo.user
            val userRole= getUserRole(user)
            val requireRoles = targetRoles as List<Int>

            // 如果没有权限则抛出异常
            if (!requireRoles.contains(userRole)) {
                throw Exception("requireRoles")
            }
            // 如果有权限则走原始DataFetcher的数据获取逻辑
            originalDataFetcher.get(it)
        }

        // 将原来的DataFetcher替换成增加了拦截功能的新的DataFetcher
        return field.transform { it.dataFetcher(dataFetcher) }
    }
}

类似增加了一个代理，在代理中处理了权限拦截。

前面的文章有说过，Instrumentation也可以在获取数据前做拦截，它和Derective的区别在于后者是配合了schema中定义的Derective，而前者是纯后端对整个流程的拦截。

除了Field，SchemaDirectiveWiring 还允许我们拦截对象、参数、枚举等等。那么，当我们把Directive注入到GraphQL引擎后，是怎么影响到GraphQL的执行流程的呢？

我们写的 SchemaDirectiveWiring 会和其他用户自定义的东东（ GraphQLScalarType、typeResolvers、EnumValuesProvider 等）包装成一个 RuntimeWiring ，一看名字就是做注入的，接着 RuntimeWiring 被传递到 SchemaParser 中， SchemaParser 会把从schema解析得到的对象构造成内存中的 GraphQLSchema，核心的方法是 parseSchemaObjects()：

fun parseSchemaObjects(): SchemaObjects {
    // 省略...

    // 创建不同的GraphQLType Object 
    val interfaces = interfaceDefinitions.map { createInterfaceObject(it) }
    val objects = objectDefinitions.map { createObject(it, interfaces) }
    val unions = unionDefinitions.map { createUnionObject(it, objects) }
    val inputObjects = inputObjectDefinitions.map { createInputObject(it) }
    val enums = enumDefinitions.map { createEnumObject(it) }

    // 省略...
}

我们把焦点集中到 createObject 上，这里的Object指的是我们在schema中定义的type，比如：

## 这是一个叫Stage的Object
type Stage{
    stageCode:String
    stageName:String
}

## 这是一个叫Query的Object
type Query{
  stages:[Stage!]! @role(roles : [101])
  subjects:[Subject!]!  @role(roles : [100]) @deprecated(reason:"is old value")
}

我们截取 createObject 中的代码进行分析：

private fun createObject(definition: ObjectTypeDefinition, interfaces: List<GraphQLInterfaceType>): GraphQLObjectType {

    // 解析到Query这个Object，建造者模式构造一个GraphQLObjectType
    val name = definition.name
    val builder = GraphQLObjectType.newObject()
            .name(name)
            .definition(definition)
            .description(if (definition.description != null) definition.description.content else getDocumentation(definition))

    // 注入绑定到Object上的Derective
    builder.withDirectives(*buildDirectives(definition.directives, setOf(), Introspection.DirectiveLocation.OBJECT))

    // 注入实现的接口
    definition.implements.forEach { implementsDefinition ->
        val interfaceName = (implementsDefinition as TypeName).name
        builder.withInterface(interfaces.find { it.name == interfaceName }
                ?: throw SchemaError("Expected interface type with name '$interfaceName' but found none!"))
    }

    // 这里是重点啦，这里会找到当前Object的字段的FieldDefinition
    definition.getExtendedFieldDefinitions(extensionDefinitions).forEach { fieldDefinition ->
        fieldDefinition.description
        // 根据schema的FieldDefinition构造GraphQLFieldDefinition，也就是构造stages这个API，不过对于GraphQL来讲，都是GraphQLFieldDefinition
        builder.field { field ->
            createField(field, fieldDefinition)
            field.dataFetcher(fieldResolversByType[definition]?.get(fieldDefinition)?.createDataFetcher()
                    ?: throw SchemaError("No resolver method found for object type '${definition.name}' and field '${fieldDefinition.name}', this is most likely a bug with graphql-java-tools"))

            // 将经过SchemaDirectiveWiring处理的stages的GraphQLFieldDefinition返回
            val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring))
            GraphQLFieldDefinition.Builder(wiredField)
                    .clearArguments()
                    .argument(wiredField.arguments)
        }
    }

    val objectType = builder.build()

    return directiveGenerator.onObject(objectType, DirectiveBehavior.Params(runtimeWiring))
}

沿着 val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring)) 继续跟，跟到 SchemaGeneratorDirectiveHelper 中找到了 SchemaDirectiveWiring 的处理：

private <T extends GraphQLDirectiveContainer> T wireForEachDirective(
        Parameters parameters, T element, List<GraphQLDirective> directives,
        EnvBuilder<T> envBuilder, EnvInvoker<T> invoker) {
    T outputObject = element;
    for (GraphQLDirective directive : directives) {
        SchemaDirectiveWiringEnvironment<T> env = envBuilder.apply(outputObject,directive);
        Optional<SchemaDirectiveWiring> directiveWiring = discoverWiringProvider(parameters, directive.getName(), env);
        if (directiveWiring.isPresent()) {
            SchemaDirectiveWiring schemaDirectiveWiring = directiveWiring.get();
            // 执行SchemaDirectiveWiring中的onField方法，完成DataFetcher的拦截
            T newElement = invoker.apply(schemaDirectiveWiring, env);
            assertNotNull(newElement, "The SchemaDirectiveWiring MUST return a non null return value for element '" + element.getName() + "'");
            outputObject = newElement;
        }
    }
    return outputObject;
}

我们回到最开始的问题，如果没用GraphQL-Java-Tools怎么注入 SchemaDirectiveWiring 呢？

答案就很显然了，我们需要自己写 GraphQLFieldDefinition，然后自己调用 val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring)) 即可，调用 directiveGenerator 很简单，但是每一个 GraphQLFieldDefinition 都要自己写就比较麻烦了。

作者：Johnny_
链接：https://www.jianshu.com/p/f76f3df9d566
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。