Parse平台多用户共享数据库访问：使用ACLs还是CLPs？

CLPs相比你当前纯ACL实现的核心优势 #

• 全局规则统一管控，降低漏配风险：CLPs是类级别的全局权限规则，不需要为每个对象单独编写权限设置逻辑。比如你要禁止所有未登录用户访问Color类，直接在CLPs中关闭公开读权限即可，不需要每个Color对象的ACL都单独排除公有权限，不会出现某次业务逻辑漏写ACL导致数据泄露的问题。
• 减少存储冗余，提升查询效率：你当前的实现中每个对象的ACL都要存储全量的用户组ID列表，如果用户组有数十上百人，每个对象都要重复存储这份列表，不仅占用额外存储资源，Parse查询时过滤ACL的耗时也会更高。CLPs是全局生效的规则，不占用单个对象的存储，权限过滤速度更快。
• 支持更细粒度的权限管控：CLPs可以单独管控find、get、create、update、delete、addField等细分操作的权限，还可以结合Pointer权限实现字段级别的管控，比如仅允许用户修改自己创建对象的指定字段，纯ACL只能统一控制对象的读写权限，无法实现这类细粒度的操作、字段级管控。
• 用户组权限调整效率更高：你当前的方案如果需要给用户组新增/移除成员，必须把所有关联的业务对象全部拉取出来重新更新ACL，当用户组关联的对象量级较大时，需要跑批量任务，耗时长且容易出错。如果用CLPs配合Parse Role能力，仅需要修改Role内的用户列表，所有关联的权限会自动生效，不需要更新任何业务对象。

你当前纯ACL实现的潜在问题 #

• 权限更新成本极高：只要用户组人员发生变动，就需要遍历所有关联的color对象重写ACL，如果后续业务扩展，用户组关联的对象不止color类，或者单个用户组关联的对象达到数千上万的量级，这个更新操作会非常缓慢，还可能触发Back4App的请求速率限制。
• 权限漏配风险高：所有对象的权限都依赖业务代码手动调用setACL，只要某一次新增对象的逻辑漏写这行代码，或者设置ACL时用错了用户组列表，就会出现权限异常，要么合法用户无法访问对应数据，要么数据直接对外公开。
• 缺少全局权限兜底：你当前的代码没有做公开读写权限的全局限制，如果不小心在ACL配置中漏关了公有权限，所有数据默认会开启公开读写，安全风险很高。CLPs可以直接全局关闭公开权限，即使代码中ACL配置错误，也有全局规则兜底不会出现数据泄露。
• 大数据量下查询性能下降：当单表数据量达到十万级以上，每个对象的ACL都包含大量用户ID时，Parse的权限过滤查询耗时会明显上升，甚至可能出现查询超时的问题。

如果你的项目只是小型演示项目，用户量和数据量都非常小，当前方案可以正常稳定运行；如果后续要上线正式业务、扩大使用规模，建议补充CLPs作为全局兜底规则，或者逐步切换到CLPs+Parse Role的权限方案。

内容的提问来源于stack exchange，提问作者RobbB