Acl

> 本文由PingCode@阿杰分享 2021年 Wiki 退出了很多强硬的个性，其中包含协同编辑 、页面权限、表情符号 等，这些性能给用户带来了更好的体验。作为 Wiki 使用者兼开发者，今日来聊聊年初上线的页面权限，同时总结一下开发阶段波及到的技术、遇到的问题以及解决方案，对于权限自己之前曾经写过一篇 Worktile 权限的文章了，Worktile 权限着重讲了 RBAC（基于角色的权限管制计划）的设计与实现，本文基于 Wiki 页面权限抉择的另一个支流权限设计的计划：ACL。 本文大抵分为三局部： ACL 介绍介绍咱们的权限以及为什么抉择它设计实现一、ACL 介绍1. 什么是 ACL？ACL：Access Control List，权限管制列表，是对文件以及目录的权限管制计划。赫赫有名的 Linux 权限零碎，它就是 ACL 的典型案例，自己在开发过程中也受到了 Linux 权限设计的一些启发。 2. ACL的应用场景应用场景也能够换个问法：为什么要应用 ACL ？对于这个问题咱们还以 Linux 作为案例：Linux 自身只提供了Owner（所有者）、Group（用户组）、Others（其余成员），也就是说其余成员或用户组是无奈指定更细粒度的权限。 为了更好的解释，咱们来举个简略的例子（场景）： 有 4 个成员有 A、B、C、D，其中 A、B、C 是开发组G的成员，A成员创立了一个代码仓库并把团队开发的代码搁置到该目录中，其中这些代码次要是对于G组的，与其余成员无关，所以A把文件目录设置了权限，权限是组内可读可写，其他人没有任何权限。 当初来剖析一下各个角色，A 是仓库的 Owner，G 是 Group（含B、C），D 是与该文件无关的成员，所以是 Others。当初入职了一个用户E，因为E是新人，所以不想让E去操作代码，只容许他查看相熟代码。 面对这种场景，试想一下如何给 E 成员设置对应权限呢？答案是 oh no，因为 E 既不能依照 G 组权限，也不能依照 Others 权限，更不能是 Owner！所以面对这种鸡肋的权限，ACL 就作为了其补充，ACL 能够反对针对某一个用户或某个用户组做独立的权限，完满解决了相似场景。 二、PingCode Wiki 权限架构OK，理解了什么是 ACL 以及应用场景，咱们来聊一下 Wiki 的权限架构，根本架构见下图。 ...