摘要：认证在非节点完成。你已经有一个或者节点，只有认证成功的用户可以访问，添加非常的简单。第三种情况一般是一个全新的后端会有的形态，尽量避免处理非节点。非节点的处理机制非节点，我是指和，或者基本认证。上面的也可以和非节点的认证方法一起使用。
GraphQL与认证
很多人会问GraphQL怎么认证和授权。最终的答案是GraphQL只是一个查询语言和认证之类的没什么关系，每一个应用都可以有自己的实现方法。但是，我们还是来深入聊聊这个问题。
大局上看基本上，有三种情况会发生：
已经登录的用户发出GraphQL查询，未登录的用户不可以。认证在非GraphQL节点完成。
所有用户都可以发出GraphQL查询，未登录用户可以使用其中的一个子集。认证在非GraphQL节点完成。
所有用户都可以发出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-graphq...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/86743.html
摘要：需要哪些数据，与开发人员在中声明该数据的方式之间存在紧密的联系。该大致表示了层可以响应的范围。为了解决多次往返的问题，让响应服务器只是作为一个端点。它需要一种语言来处理自定义请求，并响应该自定义请求的数据。一旦安装，移动应用可能会持续使用同 首发于众成翻译 即使与 REST API 打交道这么多年，当我第一次了解到 GraphQL 和它试图解决的问题时，我还是禁不住把本文的标题发在了...
摘要：前言两篇文章学完了基础篇原理篇，接下去便是实践的过程，这个实践我们使用了如下技术栈去实现一套任务管理系统，源码就不公开了等稳定后再发布。后续我所在的公司网关团队会持续实践，争取贡献出更多的解决方案。前言 两篇文章学完了GraphQL(基础篇, 原理篇)，接下去便是实践的过程，这个实践我们使用了如下技术栈去实现一套任务管理系统，源码就不公开了, 等稳定后再发布。效果如下： showImg(ht...
摘要：对于每个案例，我们插入所需要的测试数据，调用需要测试的函数并对结果作出断言。我们将这个套接字和用户返回以供我们其他的测试使用。 原文地址：Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo: an absurdly deep dive - Part 2 原文作者：Zach Schneider 译文出自：掘金翻译计划 本文永久链接：gi...
摘要：要对进行黑盒测试测试的最好办法是对他们进行黑盒测试，黑盒测试是一种不关心应用内部结构和工作原理的测试方法，测试时系统任何部分都不应该被。此外，有了黑盒测试并不意味着不需要单元测试，针对的单元测试还是需要编写的。 本文首发于之乎专栏前端周刊，全文共 6953 字，读完需 8 分钟，速度需 2 分钟。翻译自：RingStack 的文章 https://blog.risingstack.co...
摘要：最终代码省略其他输入类型用标识查询类型需要至少定义一个不要会不显示查询这里需要转成数组因为前面定义了返回值是类型相当于数据库的添加操作相当于数据库的更新操作省略其他现在我们可以启动服务器，在上测试下效果了。 showImg(https://segmentfault.com/img/remote/1460000019142304?w=893&h=438); 看完复联四，我整理了这份 Gr...
阅读 2156·2021-10-12 10:12
阅读 670·2019-08-29 17:25
阅读 2625·2019-08-29 17:24
阅读 2997·2019-08-29 17:19
阅读 1688·2019-08-29 15:39
阅读 2798·2019-08-26 16:50
阅读 1838·2019-08-26 12:17
阅读 2548·2019-08-26 12:16
