跳转到主要内容

权限

后台访问权限如何通过角色和组织进行控制。

简介​

CLUAR 通过角色（用户组）来控制对后台的访问，这些角色在组织内部被分配给人员。服务器上的每个 REST 服务都被归入某个访问类别，只有拥有正确角色、且处于正确组织中的人才能使用它。

角色​

共有 5 个预创建的角色（user_group）：

代码名称
administrator管理员
editor编辑
author作者
contributor贡献者
subscriber订阅者
并非所有角色都已分配权限

目前只有管理员和编辑真正拥有某些访问权限 —— 它们是访问规则中唯一被引用的角色（见下文）。作者、贡献者和订阅者虽然已作为表单中的选项存在，但尚未配置任何访问权限；如今给某人分配这些角色之一，并不会让他获得后台中的任何访问权限。

组织​

一个人只有在某个组织的上下文中才拥有角色 —— 该关联通过 组织 > 成员（organization_people）完成，将人员 + 组织 + 角色关联起来。

目前只有一个组织，代码为 admins，所有权限校验都在该组织中进行。organization 实体支持层级结构（parent_id，"父"组织），但该层级目前尚未用于现有的权限规则 —— 所有校验都直接指向 admins 组织。

首次进入编辑模式​

CLUAR 区分两个不同的登录位置：

  • Netuno 后台（开发环境中的 9000 端口）—— 在这里直接管理 Netuno 用户（netuno_user，即用户名/密码对）以及所有实体，包括人员和角色。
  • 网站自身的保留区域（/login，开发环境中的 3000 端口）—— 内容编辑人员日常在这里登录，以进入页面的编辑模式。

要进入保留区域并使用编辑模式，需要一个已关联到人员的、带有登录凭据的 Netuno 用户，该人员需以管理员或编辑角色关联到 admins 组织（见上文的组织）。

默认用户​

CLUAR 的 server/setup/030-people.js 默认已经创建了一个与 id: 2 的 Netuno 用户关联的 "admin" 人员，而 server/setup/050-organization_people.js 已经将该人员以管理员角色关联到 admins 组织 —— 也就是说，该用户生来就拥有完全访问权限。

该默认用户的登录信息为：

用户名：admin
密码：admin

使用这些凭据，即可直接以管理员身份进入保留区域（/login）—— 无需先在 Netuno 后台进行任何额外操作。

在生产环境中修改默认密码

admin/admin 是众所周知且可预测的凭据。在网站上线生产环境之前，请修改该用户的密码（或创建一个新的管理员并停用该用户）。

创建新用户​

有两条可行路径：

**通过保留区域（推荐）：**在 用户 > 创建用户 中，单个表单会要求填写姓名、用户名、密码、电子邮件、组织和角色 —— 并一次性创建全部内容：Netuno 用户、人员（已与该用户关联）以及与所选组织/角色的关联。无需经过 Netuno 后台。

**仅通过 Netuno 后台：**由于后台可以直接访问所有实体，也可以不离开后台手动完成同样的 3 个步骤：

  1. 创建 Netuno 用户（netuno_user），使用所选的用户名/密码。
  2. 创建人员，并将其关联到该 Netuno 用户。
  3. 在 组织 > 成员 中，将该人员以管理员或编辑角色关联到 admins 组织。

无论采用哪种方式，创建的人员都能立即登录 /login 并使用编辑模式。

权限如何生效​

服务器上的每个服务都被归入以下类别之一，这些类别在 server/core/_service_config.js 中定义：

类别谁可以访问示例
公开任何人，无需登录联系、头像、登录
内容管理管理员 + 编辑页面、版本、组件、词典、操作
网站管理仅管理员配置、语言、同步
访问管理仅管理员组织、人员、用户

任何未列入这些类别的服务都默认被拒绝 —— 这是代码中有意为之的决定（文件中已明确注释），以便在忘记归类某个新服务时导致阻塞，而不是因疏忽而开放访问。

权限在开发环境中不生效

在 dev 环境中，_service_config.js 会在任何校验之前就放开所有服务 —— 也就是说，权限只在生产/预发布环境中才真正生效。在本地测试时，任何已登录用户都可以访问一切，无论其角色如何。

界面：菜单也会按权限过滤​

除了服务器端的封锁之外，保留区域的侧边菜单（website/src/components/SideMenu）也会根据已登录人员的角色过滤可见项目 —— 以免显示该人员无权使用的选项。

保持两份列表同步

SideMenu 中的“谁能看到什么”列表是手动与 _service_config.js 中的 CONTENT_MANAGEMENT_PATHS、SITE_ADMIN_PATHS 和 ACCESS_MANAGEMENT_PATHS 保持一致的 —— 它们是两份独立的列表，一份在前端，一份在后端。添加新的受保护服务时，需要同时更新两者；只改服务器会掩盖错误（菜单仍会显示一个实际上会被拒绝的选项），而只改菜单则实际上起不到任何保护作用。

如何保护新服务​

  1. 照常在 server/services/ 中创建服务。
  2. 将服务的路径（path/method）添加到 server/core/_service_config.js 中正确的列表 —— CONTENT_MANAGEMENT_PATHS、SITE_ADMIN_PATHS 或 ACCESS_MANAGEMENT_PATHS —— 视谁应当能够使用它而定。如果是公开的，则添加到 PUBLIC_PATHS。
  3. 如果该服务在保留区域的菜单中有对应项，还要更新 SideMenu，以使过滤结果与实际权限一致。