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

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

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

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

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

确定您的客户需要的角色

我识别出CMS中用户之间可能共享或转移的责任。一个好的起点是关注每个组件，并考虑是否应该只为它设置一个角色。这可能过于简单化，但鉴于角色通常与单个组件相关联，这是一个好的开始。当然，有时一个角色将负责多个组件或复杂组件的几个部分。当你确定了一个角色时，用那些将管理网站及其内容的用户可以理解的方式定义它。

为每个角色创建一个组

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

简化组层次结构

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

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

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

不需要后端访问的角色可以共享公共或注册作为它们的父组，或者如果您觉得更直观，您可以为收集所有前端角色到一个单一父组的目的创建一个名为前端角色的组。

按角色分配权限

通常一个角色仅限于一个组件。对于每个基于角色的组，转到其关联的组件并仅向此基于角色的组授予所需的权限。一个组件仅授予权限给超级、管理员和一个基于角色的组并不罕见。事实上，撤销先前授予管理员（甚至超级）的权限，仅让基于角色的组成为唯一授予这些权限的组是合理的。

创建基于角色的访问级别

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

可以说，名字叫得不好的“访问级别”可能更好命名为“访问规则”。尽管默认的访问级别集（公共、注册、特殊）被设置为表示三个代表“级别”的层级，但在2.5版本中，访问级别本身并没有赋予级别的内在属性。访问级别仅声明一组组（任何组合，且不考虑级别）。

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

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

重构您的ACL

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

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

管理模块

基于角色方法的重大优势之一是，通过后端管理网站的人可以看到仅显示他们需要访问的仪表板。管理员菜单不应显示用户没有权限使用的功能。通过创建每个角色一个管理模块并分配每个模块到相应的基于角色的访问级别，可以以一种强大的方式自定义后端。每个这些模块可以包含仅对分配了该访问级别的用户显示的信息或快速链接。后端将仅显示与用户分配的角色相对应的模块。下面将展示这一点。

将用户分配到角色

作为网站集成商，我们有责任创建和配置与每个角色的商业理解相符合的角色。如果我们做得很好，那么我们交给客户的是一个非常直观的角色分配管理系统。这是一个简单的角色清单，每个角色都直观命名，并授予预期的权限。就这么简单。

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

总结

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

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

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