2

我试图弄清楚baqend是否可以做到这一点，或者甚至是正确的方法。

我有一堆用户，使用 Baqend 附带的默认用户帐户系统。

其中一些用户将是公司的管理员。一家公司将有 1 到 5 个管理员用户。

有一个单独的数据类，其中包含公司的记录和作为管理员的用户数组。

像这样：

{
  id: "/db/Companies/123-456-789",
  name: "Test Co",
  admins: [
    { id: "/db/Users/10", name: "Joe Schmo" },
    { id: "/db/Users/11", name: "Kate Skate" },
    { id: "/db/Users/12", name: "Johny Begood" }
  ]
}

确保只有用户 10、11 和 12 可以修改 admins 数组的内容以及 /db/Companies/123-456-789 中包含的任何其他内容的方法是什么？

是否像在数组中插入额外的管理员信息并同时或之后将该人添加到 /db/Companies/123-456-789 的 ACL 一样简单？

还有什么方法可以删除个人 ACL？我在这里看到如何设置它：https ://www.baqend.com/guide/topics/user-management/#permissions但我们如何删除或删除？在 ACL 中明确拒绝该用户与该用户根本不存在之间有什么区别（我猜默认情况下被拒绝？假设整个集合首先设置为不公开）。

对于我们的使用，仅仅因为管理员离开并不意味着他离开了我们的应用程序，他可能会为另一个使用我们应用程序的客户工作，并且他的用户帐户应该保持有效，但不能再访问公司记录。

4

2 回答 2

2

我认为您已经完全正确：您可以通过将管理员添加到admins数组中并明确允许他们在 ACL 中进行读写访问来将管理员添加到公司。要删除管理员权限，您可以简单地删除allow即将离职管理员的显式规则。

在 Baqend 中，权限是这样执行的：

  1. 超级用户总是被允许的。
  2. 明确拒绝的用户和角色总是被拒绝。
  3. 如果记录没有允许规则，则访问是公开的。只要存在至少一个允许规则，就只授予允许的用户访问权限。

由于每条记录都是公开的，除非至少有一条allow规则，因此当您允许管理员访问时，您的记录将受到保护。但是，一旦您从访问规则集中删除最后一个管理员，它就会再次公开。因此，始终明确允许对您的 Baqend 应用程序管理员进行写访问可能是一个好主意，以便始终存在至少一个allow规则。

于 2017-10-04T06:13:01.407 回答
1

让我试着解释一下 Baqend 中的 ACL 究竟是如何工作的。

TL;博士

为了保护您的对象/db/Companies/123-456-789，您只需将三个用户 ID ( /db/Users/10. /db/Users/11, /db/Users/12) 中的每一个的允许规则添加到公司对象的对象 acl 中，如下所示：

db.Companies.load("/db/Companies/123-456-789").then(function(company) {
  company.allowWriteAccess("/db/Users/10");
  company.allowWriteAccess("/db/Users/11");
  company.allowWriteAccess("/db/Users/12");

  return company.save();
})

这确保只有这些用户可以编辑公司对象。值得注意的是，此规则列表独立于公司对象中包含的管理员列表。要撤消用户的写访问权限，您可以deleteWriteAccess按照我们之前使用的相同方式使用allowWriteAccess。这意味着您的用户无需离开您的应用即可轻松离开公司。

我希望这回答了你的问题。因为 ACL 很复杂，我现在将尝试更详细地解释一般方法。

ACL 的工作原理

可以在哪个级别控制访问？

有两个级别可以控制对数据的访问：

  • 在表级别（所谓的架构 ACL）
  • 在对象级别（所谓的对象 ACL）

架构 ACL定义了一般允许谁访问表。例如，您可以通过仅授予管理员读取权限来定义用户表对公众不可读：

allowReadAccess("/db/Role/admin")  // Schema ACLs can only be set by the admin

您可以分别定义表的读取、更新、 插入和查询规则。

对象 ACL定义了较低级别的访问。您可以使用它来拒绝对特定对象的访问。例如，您可以定义只有用户本身才能更新自己的 User 对象，如下所示：

allowWriteAccess("<userId>")

对于对象，可以分别定义读写规则。

现在谁有权访问（如何评估权限）？

为了访问对象，用户需要具有访问表的一般权限（架构 ACL）以及访问对象本身的权限（对象 ACL）。这意味着如果架构 ACL 授予您访问权限，则首先评估它们，然后评估对象 ACL。

我可以定义哪些规则？

可以定义两种类型的规则来允许或拒绝访问：

  • 允许规则通常定义谁具有访问权限。首先检查这些规则。如果您不定义允许规则，则每个人都具有一般访问权限。
  • 拒绝规则定义谁被拒绝访问（即使用户被允许规则允许）。在允许规则之后检查这些规则。

查看用于 ACL 的 JS API 以获取实际的方法文档。

这些单独的规则在开始时可能会很棘手，但它们确实很强大。让我们做一些例子。我怎样才能使用这些规则来...

  1. 拒绝所有人访问：--> 为管理员设置唯一允许规则
  2. 允许登录用户访问，但不允许某些人Peter访问（例如，当您阻止某人是聊天应用程序时）： --> 为loggedin角色设置允许规则，为 Peter 设置拒绝规则。
  3. 只允许来自后端代码模块的访问： --> 为node角色设置允许规则（参见下面的角色解释）。

我可以授予或拒绝谁访问？

您可以在允许和拒绝规则中使用两个实体：

  • 可以授予或拒绝预定义用户表中的用户访问权限
  • 可以授予或拒绝预定义角色表中定义的用户组访问权限
  • 预定义角色admin，loggedin（代表所有登录用户）和node（代表访问数据库的后端代码模块）

我的表的默认访问权限是什么？

如果未进行其他配置，则默认情况下可以公开访问表和对象。

属性级 ACL 怎么样

Baqend 中没有属性级别的 ACL。这意味着当您有一个带有私人电子邮件地址和公共名称的用户对象时，您只能将该对象设为私有或公共。

解决方案是使用两个对象，一个用于私人信息，一个用于公共信息，然后将两者链接起来。对于用户，这意味着您将实际的用户对象设为私有并定义一个新的配置文件表，您可以在其中保存公共用户信息。

虽然此解决方案在定义模式时工作量更大，但Baqend 不支持属性级 ACL有充分的理由。无需过多介绍：

  1. 更好的缓存。属性级 ACL 将严重限制我们缓存的方式，从而加速您的数据库请求。
  2. 昂贵的评价。属性级 ACL 更难评估，因此会减慢数据库访问速度。另一方面，对象级 ACL 可以下推到我们的数据库系统中，并且可以非常有效地进行评估。

缺少一些东西

我希望这些解释有助于更好地理解 ACL 系统。如果这里缺少什么，只需评论，我会添加它。

于 2017-10-04T06:15:05.973 回答