Baqend中的关系和ACL [英] Relationships and ACL in Baqend

问题描述

我正在尝试使用baqend做到这一点，甚至是正确的开始方法.

I'm trying to figure out if this is possible with baqend, or even the correct approach to begin with.

我有很多用户，使用的是Baqend随附的默认用户帐户系统.

I have a bunch of users, using the default user account system that comes with Baqend.

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

Some of these users will be administrators of a company. A company will have somewhere between 1 and 5 users who are administrators.

有一个单独的数据类，其中包含公司的记录和一系列管理员用户.

There is a separate data class that contains a record for the company and an array of users who are the administrators.

赞:

{
  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中包含的其他内容?

What is the approach to ensure that only users 10, 11, and 12 can modify the contents of the admins array and whatever else is contained in /db/Companies/123-456-789 ?

是简单地将附加管理员的信息插入到数组中，还是同时或紧随该人添加到/db/Companies/123-456-789的ACL中吗?

Is it as simple as inserting the additional admin's info into the array and also adding that person to the ACL of /db/Companies/123-456-789 at the same time or right after?

此外，删除个人ACL的方法是什么?我在这里了解如何设置: https://www.baqend.com/guide/topics/user-management/#permissions ，但是我们如何删除或删除?在ACL中明确拒绝该用户与根本不存在该用户之间有什么区别(我猜默认情况下被拒绝?假设整个集合最初都设置为不公开).

Also what is the way to remove a persons ACL? I see how to set it here: https://www.baqend.com/guide/topics/user-management/#permissions but how do we do remove or delete? And what is the difference between explicitly denying that user in the ACL vs that user simply not existing (and I guess by default being denied? Assuming the entire collection is set to NOT be public in the first place).

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

For our use, just because an administrator leaves does not mean he leaves OUR APP, he might go work for another customer who uses our app and his user account should remain valid, but with no more access to the company record.

推荐答案

让我尝试解释一下Baqend中ACL的工作原理.

let me try to explain how exactly ACLs in Baqend work.

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

To secure your object /db/Companies/123-456-789 you can simply add an allow rule for each of your three user ids (/db/Users/10. /db/Users/11, /db/Users/12) to the object acls of your company object like this:

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();
})

这确保只有这些用户才能编辑公司对象.值得注意的是，此规则列表独立于公司对象中包含的管理员列表.要撤消用户的写访问权限，可以像以前使用allowWriteAccess一样使用deleteWriteAccess. 这意味着您的用户无需离开您的应用程序即可轻松离开公司.

This ensures that only these users can edit the company object. Notably, this list of rules is independent of the list of admins contained in your company object. To revoke the write access of a user, you can use deleteWriteAccess in the same way we used allowWriteAccess before. This means your users can leave a Company easily without leaving your app.

我希望这能回答您的问题.由于ACL很复杂，因此我将尝试更详细地解释通用方法.

I hope this answers your question. Because ACLs are complex I will try to explain the general approach in more detail now.

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

There are two levels to control access to your data:

• 在表级别(所谓的架构ACL)
• 在对象级别(所谓的对象ACL)

架构ACL 定义允许谁访问常规中的表.例如，您可以通过仅授予管理员读访问权限来定义User表对于公众不可读:

Schema ACLs define who is allowed access to the table in general. For example, you could define that the User table is not readable for the public by granting read access only to the admin:

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

您可以在表格上分别定义阅读，更新，插入和查询的规则.

You can define rules for reading, updating, inserting and querying on the table separately.

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

Object ACLs defines access on the lower level. You can use it to deny access to a specific object. For example, you could define that only the user itself can update its own User object, like this:

allowWriteAccess("<userId>")

对于对象，您可以分别定义阅读和写作的规则.

For objects, you can define rules for reading and writing separately.

为了访问对象，用户需要具有访问表的一般权限(模式ACL)以及访问对象本身的权限(对象ACL).这意味着，如果架构ACL授予您访问权限，则将首先评估架构ACL，同时也会评估对象ACL.

In order to access an object, a user needs to have general permission to access the table (Schema ACLs) and also permission to access the object itself (Object ACLs). This means the Schema ACLs are evaluated first if they grant you access, the Object ACLs are evaluated as well.

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

There are two types of rules that can be defined to allow or deny access:

• 允许规则定义了一般具有访问权限的人.首先检查这些规则.如果您未定义允许规则，则每个人都具有常规访问权限.
• 拒绝规则定义了拒绝访问的用户(即使允许规则允许了用户).在允许规则之后检查这些规则.

• Allow Rules define who has access in general. These rules are checked first. If you do not define allow rules, everyone has general access.
• Deny Rules defines who is denied access (even if the user was allowed by an allow rule). These rules are checked after the allow rules.

看看用于ACL的JS API 实际方法文档.

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

These separate rules can be tricky at the start but they are really powerful. Let's do some examples. How can I use these rules to ...

1. 拒绝所有人访问:->为管理员设置唯一的允许规则
2. 允许登录用户访问，但不允许某些人 Peter 访问(例如，当您阻止某人是聊天应用程序时):->为loggedin角色和拒绝彼得的统治.
3. 仅允许从后端代码模块进行访问:->为node角色设置允许规则(有关角色的说明，请参见下文).

1. Deny access for everyone: --> Set the only allow rule for admin
2. Allow access for logged-in users but not for some guy Peter (like when you block someone is a chat application): --> Set an allow rule for the loggedin role and a deny rule for Peter.
3. Only allow access from backend code modules: --> Set an allow rule for the node role (see below for the explanation of Roles).

我可以授予或拒绝谁访问权限?

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

Who can I grant or deny access?

There are two entities you can use in your allow and deny rules:

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

• Users from the predefined User table can be granted or denied access
• Groups of Users defined in the predefined Role table can be granted or denied access
• The predefined roles admin, loggedin (represents all logged-in users) and node (represents backend code modules that access the database)

默认情况下，表和对象是可公开访问的，除非另行配置.

Tables and objects are publically accessible by default if not configured otherwise.

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

There are no attribute level ACLs in Baqend. This means when you have a User object with a private email address and a public name you can only make the object private or public.

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

The solution for this is to use two objects, one for the private information and one for the public information and then link the two. For the User, this would mean you make the actual User object private and define a new Profile table where you keep the public user information.

尽管在定义架构时此解决方案更有效，但有充分理由，为什么Baqend不支持属性级ACL.无需赘述:

While this solution is more work when defining your schema, there are good reasons why Baqend does not support attribute-level ACLs. Without going into too much detail:

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

缺少某些东西

我希望这些解释有助于更好地了解ACL系统.如果此处缺少某些内容，请发表评论，然后我将其添加.

Something missing

I hope these explanations help to understand the ACL system better. If there is something missing here, just comment and I will add it.

这篇关于Baqend中的关系和ACL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！