Question

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

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

/Travels列出了用户拥有的所有旅行
/Travels/public列出所有公共旅行
/Travels/{id}/join使用指定ID加入旅行

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

每字段ACL也是如此。假设您有一些清单项目，一些是手动添加的，另一些是自动生成的。你能否只在自动阻止WRITE操作，除了改变＆＃34;完成＆＃34;场？

Answer 1

默认情况下，请求

GET /Travels

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

GET /Users/{id}/Travels

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

关于/Travels/public这是微不足道的，您只需要创建一个remote method。使用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获取用户在您的应用程序中进行身份验证。

LoopBack用户特定的数据过滤/访问

1 个答案: