GraphQL与认证

GraphQL与认证

很多人会问GraphQL怎么认证和授权。最终的答案是GraphQL只是一个查询语言和认证之类的没什么关系,每一个应用都可以有自己的实现方法。但是,我们还是来深入聊聊这个问题。

大局上看

基本上,有三种情况会发生:

  1. 已经登录的用户发出GraphQL查询,未登录的用户不可以。认证在非GraphQL节点完成。
  2. 所有用户都可以发出GraphQL查询,未登录用户可以使用其中的一个子集。认证在非GraphQL节点完成。
  3. 所有用户都可以发出GraphQL查询,认证就由GraphQL节点完成。

第一种情况可能是普遍存在的。你已经有一个REST或者RPC节点,只有认证成功的用户可以访问,添加/graphql非常的简单。不好的地方是,你的客户端不得不处理GraphQL和非GraphQL两种情况。这可能是一笔技术债。

第二种情况是第一种项目进化以后的结果。最终前端代码只使用GraphQL,只不过久经考验的认证节点还会留着。

第三种情况一般是一个全新的后端会有的形态,尽量避免处理非GraphQL节点。我(作者)还没有见过这样形态的服务端。

非GraphQL节点的处理机制

非GraphQL节点,我是指cookies、JSON和web tokens,或者HTTP基本认证。基本上无论何种方式,你的server都可以通过认证一个用户、一个请求并最终把数据传输给你的resolver。

这里是一个使用express-graphql和cookies是例子(从他们的例子里结果来的):

var session = require('express-session');
var graphqlHTTP = require('express-graphql');
var MySchema = require('./MySchema');
var app = express();

app.use(session({ secret: 'secret', cookie: { maxAge: 60000 }}));

app.use('/graphql', graphqlHTTP((request) => ({
  schema: MySchema,
  rootValue: { session: request.session },
  graphiql: truem
})));

在express里,请求在一个比GraphQL路由更早的中间件处理了。之后,请求才会到达GraphQL代码。我们知道请求是从哪里来的。我们甚至都可以在请求到达GraphQL代码以前,把请求重定向到登录页面。

下面的例子使用了express-session,但是处理的原则和express-jwt差不多。在GraphQL层面上,你的schema代码会是这样的:

new GraphQLObjectType({
  name: 'Secrets',
  fields: {
    bigSecret: {
      type: GraphQLString,
      resolve(parentValue, _, { rootValue: { session } }) {
        return getBigSecret(session);
      }
    }
  }
});

只要能取到session,那么用户就可以访问其他相关的资源了。或者,如果session不存在,那么你按照你的设计抛出错误或者实现其他的处理。

关键是rootValue并没有在我们的GraphQL模式中定义为一个公开的字段或者参数,我们不信任客户端直接发送过来的数据,所以它是由server的其他代码注入的。

使用GraphQL时的实现机制

但是我们要完全的使用GraphQL呢?以上的方法可以在使用了express-graphql的时候使用。但是无法迁移到其他的实现里。

在少数的例子里,Facebook谈到了 concept of a viewer field。主要的思想是你的应用的数据和谁访问相关,所以全部的其他字段的数据都嵌入到里面。实际情况是,不可能所有的数据都和访问者相关。但是这么做的话,你可以有改变的余地。

{
  viewer {
    name
    friends {
      name
    }
    getProfile(id: String!) {
      name
    }
  }
}

注意即使和访问者无关的getProfile字段也放在了viewer字段里,为了以防万一哪天要限制访问者可以访问的数据的时候处理起来就简单了。

一个像Facebook一样的APP为了保护隐私,有很多什么人可以查看什么数据的逻辑处理。即使是一个简单的APP也不会让用户查看他没有创建的数据。一个常用的方法是修改URL里的userID来查看一些私有数据,如果server不检查用户所有权的话。使用一个单一的viewer字段就让所有权检查简单了很多。

上面的schema也可以和非GraphQL节点的认证方法一起使用。但是如果我们这么干的话呢:

{
  viewer(token: String) {
    name
  }
}

如果不是用header或者查询参数(比如:JWT、OAuth、等),我们可以把它放在GraphQL的查询里。你的schema的代码可以使用JWT库等工具直接解析传过来的token

**注意**:永远使用HTTPS来传输敏感数据。

要发出新的token,mutation就可以使用了:

mutation {
  createToken(username: String!, password: String!) {
    token
    error
  }
}

我们可以认证放在mutation里,要么返回一个token要么返回一个错误。这样前端就可以把token存起来在之后的请求里使用了。

译自:https://medium.com/the-graphqlhub/graphql-and-authentication-b73aed34bbeb#.8sif1n1lj

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 135,850评论 19 139
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 176,005评论 25 709
  • 第一章 Nginx简介 Nginx是什么 没有听过Nginx?那么一定听过它的“同行”Apache吧!Ngi...
    JokerW阅读 32,914评论 24 1,002
  • 原文标题:GraphQL vs. REST Two ways to send data over HTTP: W...
    iamfanny阅读 19,327评论 4 29
  • 我们从虚无中来,又要回到虚无中去,虚无才是我们的家,可是以虚无为家,不正是无家可归了吗?从虚无到虚无,人类经过一段...
    六月雨JuneRain阅读 2,312评论 0 0

友情链接更多精彩内容