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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 141,390评论 1 297
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 60,682评论 1 254
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 93,205评论 0 211
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 40,718评论 0 171
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,406评论 1 250
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,590评论 1 170
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,271评论 2 267
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,052评论 0 163
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 28,801评论 6 227
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,404评论 0 212
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,176评论 2 212
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,489评论 1 222
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,156评论 0 31
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,031评论 2 210
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,402评论 3 201
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,583评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 25,927评论 0 163
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,352评论 2 228
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,478评论 2 229