角色代表完成一项任务所需的权限和访问权限。一旦设置了角色，就可以直观地分配、聚合、转移和共享这些角色给 CMS 用户。以下是 Joomla 中实现角色的直接方法。

在之前的一篇文章中，我提出了基于角色访问控制的案例，当网站将由多个人管理时。角色使用直观，角色分配对应于员工不断变化和多样的责任，并且设计良好的角色可以授予用户恰好需要的访问权限和权限，而不会更多。

基于角色的方法与我们在 1.5 中使用的基于级别的方法和 2.5 中的默认 ACL 配置不同。考虑传统的作者->编辑->出版者的组。除非业务规则要求编辑始终是作者，出版者始终是编辑的限制，否则没有必要像那样继承。相反，每个都可以将公共作为其父级，使我们能够将用户分配给这三个独立角色的任何配置。谁说出版者也必须是作者呢！

基于角色的方法跨越了基于级别的观点认为的边界，以及 2.5 所消除的边界。

在实现角色时，我们可以自由地创建新的组和访问级别，建立我们新组的相对扁平的层次结构，并稀疏地分配权限。在基于级别的框架中，这些做法似乎是错误的。为了获得灵感，我们需要超越传统的 ACL 配置。以下是实现 Joomla 中角色的方法。

确定您的客户需要的角色

我识别出用户之间可能共享或转移的内容管理系统（CMS）责任。一个好的起点是关注每个组件，并考虑是否应该为它设置一个专门的角色。这可能会过于简单化，但鉴于角色通常与单个组件相关联，这是一个不错的起点。当然，有时一个角色将负责多个组件或复杂组件的几个部分。当你确定一个角色时，请用那些将管理网站及其内容的个人能够理解的语言和范围来定义它。

为每个角色创建一个组

我们将使用Joomla的“用户组”来表示角色。每个角色都有自己的组。如果你确定了12个角色，你需要添加12个新的用户组。每个组将赋予一组独特的权限和访问权限，仅限该角色使用——不多也不少。你为组使用的名称将是客户在分配用户到角色时看到的角色名称，因此请选择一个直观的名称，即使它需要多个单词。

简化组层次结构

大多数角色将与其他角色并列，层次结构将很浅。这与我们在1.5和2.5版本中看到的组继承不同，在那里兄弟组很少，线性继承很常见。相比之下，大多数基于角色的组将共享相同的父组，因为大多数角色是相互独立的，应该可以分配用户到任何组合的角色，而不会重叠或冲突。

假设基于角色的组将是彼此的兄弟，但请注意，有两个常见的原因需要额外一级继承：（1）当多个组共享一些权限集或一些访问级别时，创建一个表示这些共享权限或访问的父组是有意义的。（2）当一个角色应该包括另一个角色的所有权限和访问，并在此基础上扩展时，这个扩展的角色应该从其基础角色继承。

通常，几个角色需要后台访问，这是创建允许管理员登录的父组的好理由。所有后台角色都将共享这个作为它们的父组。一个赋予后台访问权限的组需要关注两个设置。首先，转到全局配置并设置该组的权限以允许管理员登录。其次，如果你想将这些用户显示在管理员菜单中（对于某些网站你可能不想这样做），你需要将这个新组添加到访问级别特殊。为什么？管理员菜单设置为访问级别特殊，你负责将你创建的任何组添加到适当的访问级别。

不需要后台访问的角色可以共享公共或注册作为它们的父组，或者如果你发现这样做更直观，你可以创建一个名为前端角色的组，专门用于将所有前端角色汇集到一个父组下。

按角色分配权限

通常，一个角色仅限于一个组件。对于每个基于角色的组，转到其关联的组件（s）并仅向该基于角色的组授予所需的权限。一个组件仅授予权限给超级、管理员和一个基于角色的组的情况并不少见。实际上，合理地撤回先前授予管理员（甚至超级）的权限，仅留下基于角色的组作为唯一授予这些权限的组是合理的。

创建基于角色的访问级别

在这里理解访问级别如何融入ACL是有帮助的。从机械角度来看，访问级别不过是用户组的一些自定义分组。在应用中，访问级别代表用户必须满足的准则，以确定该用户是否属于访问级别（从而有资格访问）。模块、菜单项、插件、类别以及每个项目本身都必须分配到访问级别。这种分配实际上是一种规则分配，它指示joomla是否显示项目或处理插件——这是基于用户组分配的间接指示。

可以说，这个名字起得不好的“访问级别”应该被称为“访问规则”。虽然默认的访问级别集合（公开、注册、特殊）被设置为代表三个层次，代表“级别”，但在2.5版本中，访问级别本身并没有内在的级别属性。访问级别仅声明一组组（可以是任何组合，并且没有对级别的认识）。

我们将利用这个认识来发挥我们的优势。如果网站的任何部分（类别、管理模块、菜单项等）只应向分配此角色的用户开放，那么我们创建一个只包括此组的基于角色的访问级别。目前我们将此设置为一对一关系，以便此访问级别只为分配此角色的用户提供访问权限。如果用户未分配此角色，则无法访问。请注意，基于角色的访问级别并非总是必需的，但如果您有任何仅在用户分配了特定角色时才显示的编辑选项，那么您将需要一个相应的访问级别。

命名约定有助于我们管理可能变得相当复杂的列表。我在每个基于角色的访问级别前加一个波浪号（~）。由于访问级别是按字母顺序排列的，这有助于将基于角色的访问级别捆绑到一起，并将它们与传统集合（公开、注册、特殊）分开。

重构ACL

“重构”是指将冗长或不必要的复杂事物简化。在数学中，我们重构15/25为3/5。在编程中，我们简化冗长的代码，以用更少的行数以更易于维护的方式进行相同的事情。

在这里，我们评估我们创建的组和访问级别，并寻找合理的方法进行简化。可能一组组需要一个新的组作为共享父组以共享权限，或者访问级别。可能某些基于角色的访问级别实际上并不需要，或者需要将一个或多个合并为一个单一的访问级别。如果一切正常，则不需要重构，但重构您的ACL可能导致更直观的配置。

管理模块

基于角色的方法的一个重大优势是，通过后端管理网站的人可以查看仅显示他们需要访问的仪表板。管理菜单不应显示用户无权使用的选项。通过创建每个角色一个的管理模块，并将每个模块分配给相应的基于角色的访问级别，可以强大地自定义后端。每个这些模块可以包含仅向分配了该访问级别的用户显示的信息或快速链接。后端将仅显示与用户分配的角色相对应的模块。以下将进行说明。

将用户分配到角色

作为网站集成商，我们有责任创建和配置与每个角色对应的业务理解。如果我们做得好，那么我们提供给客户的角色分配系统将非常直观。这是一个简单的角色清单，每个名称都直观，并赋予人们预期的权限。就是这样简单。

可能不会立即明显的是“用户管理”角色的需求。这个特殊角色允许创建用户、调整设置和分配基于角色的组。忠实于基于角色的理念，这个角色允许我们授予某人管理用户的权限，而无需将其提升为管理员。不要忘记创建这个角色。

摘要

为了强化这种简单直接的方法，以下是创建用户管理员角色的简单步骤。

1. 创建一个新的组。命名为“用户管理”。其父级应该是授予后端访问权限的组。如果您没有这样的组，创建父级组，并为此父级组分配管理员登录权限，并将其添加到访问级别特殊。
2. 分配所需的权限。从后端进入用户管理器屏幕，选择选项。在用户管理部分（仅在此部分）允许所有权限，除了“配置”。不要设置其他任何权限。
3. 访问级别。在这种情况下，我们不需要基于角色的访问级别，因为主菜单将自动显示给有权限访问的人。但是，如果您想提供一些只对用户管理员显示的行政模块，那么您需要为这个角色创建基于角色的访问级别。
4. 将用户分配给仅此角色。然后测试您的设置。以这个用户的身份登录后端，观察我们为用户管理创建的简单性。

本文提供了一种快速设置Joomla角色的方法。这并不难，但实施基于角色的ACL确实需要新的视角。你准备好了吗？