2

目前正在测试一堆框架以确定我公司未来使用的良好候选者，LoopBack 几乎完美地满足了我的需求而引起了我的注意。

但是，我感觉他们的 ACL 模型在某些情况下非常有限。让我们来看以下用例：在协作旅行管理网站上，用户可以创建和/或加入公共旅行。让我们假设以下 API：

  • /Travels列出用户的所有旅行
  • /Travels/public列出所有公共旅行
  • /Travels/{id}/join使用给定 ID 加入 Travel

构建这样的 API 是否需要重新发明轮子？还是要实现一些中间件？

每字段 ACL 也是如此。假设您有一些清单项目，有些是手动添加的，有些是自动生成的。除了更改“完成”字段之外，您能否仅在自动操作上阻止 WRITE 操作？

4

2 回答 2

6

默认情况下，请求

GET /Travels

将列出 Travel 模型的每个元素。如果您设置适当的关系（可能是用户和旅行之间的多对多关系），则查询给定用户旅行的正确方法是

GET /Users/{id}/Travels

Travels.find()但是您可以自定义使用钩子、范围甚至重载方法原型的默认行为。

关于/Travels/public这很简单，您只需要创建一个远程方法。使用该path属性自定义端点。

最后，加入带有请求的旅行/Travels/{id}/join也将使用远程方法进行管理，但这应该是一个 POST 请求。

Loopback 能够在不指定关系表的情况下管理多对多关系，但在您的情况下，我宁愿定义它。例如

{
"name": "UserTravel",
  "options": { ... },
  "properties": {
    "id":{"type":"Number", "id":1},
    "userId":{"type":"Number"},
    "travelId":{"type":"Number"}
  },
  "relations": {
    "Travel": {
        "type": "belongsTo",
        "model": "Travel",
        "foreignKey": "travelId"
    },
    "User": {
        "type": "belongsTo",
        "model": "User",
        "foreignKey": "userId"
    }
  }
}

join手头有此模型将允许您在调用端点时插入特定的用户/旅行元组。您从请求参数中获取 travelId，从请求 accessToken 中获取 userId，提供用户在您的应用程序中经过身份验证的提供程序。

于 2014-11-13T16:14:55.383 回答
2

正如@amenadiel 建议的那样，您可以使用挂钩来设置登录用户的默认过滤器：

MyModel.observe('access', function limitToTenant(ctx, next) {
  ctx.query.where.tenantId = loopback.getCurrentContext().tenantId;
  next();
});

从 docs得到这个。

于 2015-12-20T04:06:42.480 回答