0

我有一个应用程序需要根据请求用户和请求的资源之间的关系进行授权。访问详细信息封装在要请求的资源中。

让我们走这条路线PATCH /articles/1：文章有一个作者/所有者和一组编辑，他们都有权更新文章。请求用户经过身份验证，可以是作者或编辑之一。否则，应拒绝访问。

--

我有两个想法：

  1. 中间件中的授权：
    这意味着在控制器可以做它的事情来聚合资源之前，中间件已经需要资源。但是，有时（例如在使用 MongoDB 聚合框架时）控制器将无法重用资源并需要再次往返数据库。

  2. 控制器中的授权：
    只要资源可用/聚合，就可以在控制器中执行授权。但这会将这部分授权与身份验证和基于角色的访问控制分开，我已经作为中间件使用。

我个人认为中间件方式更有意义，但是数据库将由另一个 PaaS 托管，即使在同一个数据中心内，也可能会有一些延迟。

如果请求相关资源（例如评论）怎么办？这将涉及一些特定的逻辑，这些逻辑来自对存储访问详细信息的文章的评论。并且会使我的身份验证中间件不那么通用。

--

还有其他选择吗？

--

该应用程序使用Koa，但这些概念可能适用于所有其他中间件支持框架，例如Express或其他框架。

请注意，我不是在询问身份验证或经典的基于角色的访问，例如由connect-roles.

4

1 回答 1

0

我的正常模式是使用路由参数从数据库中获取资源，例如：

app.param("articleId", function (req, res, next, paramValue) {
  var _id;
  try {
    _id = new ObjectID(paramValue);
  } catch (error) {
    res.status(400).send('Invalid ID');
    return;
  }
  Article.findById(_id, function(error, doc){
    if (error) {
      next(error);
      return;
    }
    if (doc) {
      req.article = doc;
      next();
      return;
    }
    res.send(404);
  });
});

然后我使用中间件进行授权，但它可以假设req.article已经从数据库加载。

这是一个很好的默认模式，我认为你应该在做任何性能优化之前使用它一段时间并习惯它，但是当你真的有足够的流量来选择一个不太通用的模式时，就去吧。请记住，通常在启动/项目的第 2 年或第 3 年是合理的，而不是在发布日。

于 2014-04-18T01:45:05.787 回答