常见 CMS 角色和访问级别

Question

我目前正在编写一个 CMS，记得有人（可能就在这里）批评现有的 CMS 没有足够强大的用户权限系统。 我已经计划好了一个方法，但我觉得它已经陷入了通常的陷阱，即粒度太细，这使得理解和实现它对最终用户来说是一件可怕的事情。

我认为拥有一系列具有权限的默认用户角色将是这个问题的答案，所以我想我的问题是：

您希望在 CMS 中看到哪些默认角色以及与这些角色相关联的权限类型是什么？

提前致谢！

Answer 1

这是我在大多数项目中最终得到的“最佳实践”，并且对此感到非常满意：

1。 角色

说到角色，我建议具有很大的灵活性，即能够自由创建和定义用户帐户和组（“贡献者”、“经理”等角色不是硬编码的，而是放入可以根据应用程序更改的配置文件中）。 用户无法访问角色配置，但引擎本身应该不受硬编码角色的影响。

2. 权利

权利是指事情需要易于理解和实施。

我在使用和检查代码/API级别的非常细粒度的权限方面取得了非常好的经验：

• 请参阅
• 视图、
• 编辑、
• 更改名称、
• 重命名、
• 删除、
• 移动
• 、更改权限
• 等，

但是用户从来没有见过那些。 对于他们来说，它们被分组为极少数的“右组”：

• 只读、
• 编辑、
• 管理=移动、重命名……

用户永远看不到“移动”右，而只看到“管理”权限组。

这样，您就可以在未来的代码中保留细粒度权限的全部权力 - 例如，您可以轻松适应诸如“实习生必须能够编辑页面，但不能编辑页面”之类的规则能够更改它们的标题，也不能删除它们”，为 CMS 添加了宝贵的资产。 对于最终用户来说，此功能仍然不可见，并且权限系统易于使用。

Answer 2

我不久前问过这个问题并得到了以下答复。

admin           //Manage everything
manager         //Manage most aspects of the site
editor          //Scheduling and managing content
author          //Write important content
contributors    //Authors with limited rights
moderator       //Moderate user content
member          //Special user access
subscriber      //Paying Average Joe
user            //Average Joe

Answer 3

您是否研究过 RBAC 等现有解决方案？ 虽然这样的系统对于你想要破解的特定坚果来说很可能完全是过度杀伤力，但它至少有助于增强你走在正确轨道上的信心。

除此之外，我期望的一般角色如下：

管理员 - 系统的完全控制，可以查看日志（因为您应该记录所有更改 ）等加上...

发布者 - 可以实时发布内容加上...

作者 - 可以创建内容

但是，这些角色如何在整个系统中应用是事情的关键变得棘手，因为特定用户可能对不同的内容区域/模块拥有不同的权限。

Answer 4

管理员 - 可以创建用户 + 下面所有

编辑 - 可以编辑其他人的帖子 + 下面所有

作者 - 可以写帖子，编辑自己的帖子

Answer 5

创建者 - 负责创建和编辑内容。

编辑 - 负责调整内容消息
以及交付方式，包括翻译和
本土化。

发布者 - 负责发布内容
使用。

管理员 - 负责管理访问
对文件夹和文件的权限，通常已完成
通过为用户组或角色分配访问权限。

消费者、观众或访客-阅读或阅读的人
以其他方式吸收内容发布后或
共享。

Answer 6

管理员：拥有所有权利的人

作者：对特定内容拥有所有权利的人（例如拥有博客的博客作者），还拥有以下权限：添加/邀请用户协作/查看内容

协作者：可以编辑/添加作者授予权限的内容，不能删除内容或邀请/添加更多协作者

查看者< /strong> ：如果作者邀请查看内容，则可以查看内容

编辑 ：可以批准/编辑所有类型的内容

期望高级用户/开发人员使用 CMS。 但对于新的 CMS 管理员来说，基本角色使系统更加可用。

Answer 7

我不一定会忽视您现在拥有的细粒度控制系统。 如果您有一个适应性强的产品，那么重点是通过提供简化的接口来隐藏复杂性（例如，使用外观模式或适配器模式）。 好处是您为用户提供了简化版本（像“管理员”这样的简单权限可以“删除”“帖子”），同时仍然保留细粒度的功能（如果您稍后需要它们）（例如，更复杂的权限处理是允许删除当该帖子是您自己在类别 X 中的帖子时发布的帖子）。 然后，您可以在某些地方提供简化版本的替代方案以满足该需求。

Answer 8

对于大多数应用程序，我认为对于 CMS 来说也是如此，我的客户通常更喜欢以权限为导向的方法。 事情是这样的：

1. 列出主要操作。 在您的 CMS 中，这将是：创建和编辑内容； 删除内容； 对内容进行分类/分类； 验证内容； 发布内容； 管理用户； 等等。
2. 您定义每个用户允许或拒绝哪些操作

为了让事情变得更好一点，您可以创建多个角色（编辑者；管理员）以使典型用户的创建更容易（通过在选择角色时预先填写表单）。

Answer 9

我有一个基于 Zend Framework 构建的自定义 CMS，它使用 Zend 的 ACL 来扩展一些基本角色（因此您可以专门拒绝其他用户的资源或允许其他人访问他们通常无法访问的资源）。 我的基本角色从 CMS 用户一直到网站“成员”，如下所示（我只使用一个用户表来存储我的所有身份验证）。

开发人员

编辑任何内容、编辑布局、设置、配置。 使用可以调用 shell 脚本并强制执行 cron 作业的特殊工具。

管理员

编辑任何内容、编辑布局、设置。

作者

编辑内容。

会员

可以查看登录屏幕、忘记密码和错误报告。

现在，Zend 有一个很好的 ACL 实现，因此您可以轻松扩展基本 ACL 类并添加从基本角色扩展的新角色。 因此，我可能会创建一个有权访问开发人员工具之一（例如清除或缓存管理）的“管理员”，或者锁定作者使其只能管理博客（而不是例如新闻）。