15

Facebook 的官方说法是 Relay “故意不知道身份验证机制”。在 Relay 存储库中的所有示例中，身份验证和访问控制是一个单独的问题。在实践中，我还没有找到一种简单的方法来实现这种分离。

Relay 存储库中提供的示例都具有根模式，其中包含一个viewer假设有一个用户的字段。该用户可以访问所有内容。

然而，实际上，一个应用程序有很多用户，每个用户对每个节点的访问程度都不同。

假设我在 JavaScript 中有这个模式：

export const Schema = new GraphQLSchema({
    query: new GraphQLObjectType({
        name: 'Query',
        fields: () => ({
            node: nodeField,
            user: {
                type: new GraphQLObjectType({
                    name: 'User',
                    args: {
                        // The `id` of the user being queried for
                        id: { type: new GraphQLNonNull(GraphQLID) },
                        // Identity the user who is querying
                        session: { type: new GraphQLInputObjectType({ ... }) },
                    },
                    resolve: (_, { id, session }) => {
                        // Given `session, get user with `id`
                        return data.getUser({ id, session });
                    }
                    fields: () => ({
                        name: {
                            type: GraphQLString,
                            resolve: user => {
                                // Does `session` have access to this user's
                                // name?
                                user.name
                            }
                        }
                    })
                })
            }
        })
    })
});

从查询用户的角度来看，一些用户是完全私有的。其他用户可能只向查询用户公开某些字段。因此，要获得用户，客户端不仅必须提供他们正在查询的用户 ID，而且还必须标识自己，以便进行访问控制。

这似乎很快变得复杂，因为控制访问的需要在图表中逐渐减少。

此外，我需要控制每个根查询的访问，例如nodeField. 我需要确保每个节点都实现nodeInterface.

所有这些似乎都是重复性的工作。是否有任何已知的模式可以简化这一点？我想错了吗？

4

3 回答 3

7

不同的应用程序对访问控制的形式有非常不同的要求，因此在基本的 Relay 框架或 GraphQL 参考实现中加入一些东西可能没有意义。

我见过的一种非常成功的方法是将隐私/访问控制融入数据模型/数据加载器框架。每次你加载一个对象，你不会只是通过 id 加载它，还要提供查看器的上下文。如果查看者看不到对象，它将无法加载，就好像它不存在一样，以防止甚至泄漏对象的存在。该对象还保留查看器上下文，并且某些字段可能具有在从对象返回之前检查的受限访问。在较低级别的数据加载机制中进行烘焙有助于确保较高级别产品/GraphQL 代码中的错误不会泄露私有数据。

在一个具体的例子中，我可能不被允许看到某个用户，因为他阻止了我。一般情况下，您可能会被允许看到他，但不能看到他的电子邮件，因为您不是他的朋友。

在这样的代码中：

var viewer = new Viewer(getLoggedInUser());
User.load(id, viewer).then(
  (user) => console.log("User name:", user.name),
  (error) => console.log("User does not exist or you don't have access.")
)

尝试在 GraphQL 级别上实现可见性有很大的泄露信息的可能性。想想在 Facebook 的 GraphQL 实现中访问用户的多种方式：

node($userID) { name }
node($postID) { author { name } }
node($postID) { likers { name } }
node($otherUserID) { friends { name } }

所有这些查询都可以加载用户名，如果用户阻止了你，它们都不应该返回用户或其名称。对所有这些字段进行访问控制并且不要忘记在任何地方进行检查是在某处丢失检查的秘诀。

于 2015-11-07T01:00:03.633 回答
4

我发现如果使用 GraphQL 处理身份验证很容易rootValue，当针对模式执行查询时，它会传递给执行引擎。此值在所有执行级别都可用，并且对于存储访问令牌或任何标识当前用户的内容很有用。

如果您使用的是express-graphql中间件，您可以将会话加载到 GraphQL 中间件之前的中间件中，然后配置 GraphQL 中间件以将该会话放入根值中：

function getSession(req, res, next) {
  loadSession(req).then(session => {
    req.session = session;
    next();
  }).catch(
    res.sendStatus(400);
  );
}

app.use('/graphql', getSession, graphqlHTTP(({ session }) => ({
  schema: schema,
  rootValue: { session }
})));

然后，此会话在架构中的任何深度都可用：

new GraphQLObjectType({
  name: 'MyType',
  fields: {
    myField: {
      type: GraphQLString,
      resolve(parentValue, _, { rootValue: { session } }) {
        // use `session` here
      }
    }
  }
});

您可以将此与“面向查看器”的数据加载配对以实现访问控制。查看https://github.com/facebook/dataloader，它有助于创建这种数据加载对象并提供批处理和缓存。

function createLoaders(authToken) {
  return {
    users: new DataLoader(ids => genUsers(authToken, ids)),
    cdnUrls: new DataLoader(rawUrls => genCdnUrls(authToken, rawUrls)),
    stories: new DataLoader(keys => genStories(authToken, keys)),
  };
}
于 2016-02-08T13:35:47.067 回答
2

如果有人对此主题有疑问：我根据 dimadima 的回答为 Relay/GraphQL/express 身份验证制作了一个示例repo 。它使用 express 中间件和 GraphQL Mutation 将会话数据（用户 ID 和角色）保存在 cookie 中

于 2016-03-29T09:58:42.837 回答