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

在之前的一篇文章中，我提出了在网站由多个人管理时，基于角色的访问控制方法的优势。角色易于使用，角色分配与员工的多样化和不断变化的责任相对应，并且设计良好的角色可以授予用户刚好所需和不超过的访问权限和权限。

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

基于角色的方法打破了基于级别的观点所认为的界限，而2.5已经消除了这些界限。

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

确定客户需要的角色

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

为每个角色创建一个组

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

简化组层次结构

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

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

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

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

按角色分配权限

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

创建基于角色的访问级别

在这里理解访问级别如何融入ACL是有帮助的。从机械上讲，访问级别不过是用户组的某种自定义分组。在实际应用中，访问级别代表用户必须满足的准则，以确定该用户是否为访问级别的成员（因此有权限）。模块、菜单项、插件、分类甚至每个项目都必须分配到访问级别。这种分配实际上是一种规则分配，它指示joomla是否将显示项目或处理插件——间接基于用户的组分配。

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

我们将利用这种实现的优势。如果网站的任何部分（类别、管理员模块、菜单项等）应该只对分配此角色的人可访问，那么我们将创建一个基于角色的访问级别，只包含这个组。目前我们将它设置为一对一的关系，以便这个访问级别只为那些被分配此角色的人提供访问权限。如果一个用户没有被分配此角色，他们无法访问它。请注意，基于角色的访问级别并不总是需要的，但如果你有任何要显示给用户特定角色的编辑选项，那么你需要相应的访问级别。

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

重构访问控制列表

“重构”是将冗长或过于复杂的事物简化。在数学中，我们将15/25重构为3/5。在编程中，我们简化冗长的代码，使其以更少的行数和更易于维护的方式完成相同的事情。

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

管理员模块

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

将用户分配给角色

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

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

总结

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

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

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