GraphQL(五):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 都要自己写就比较麻烦了。