189 lines
13 KiB
Markdown
189 lines
13 KiB
Markdown
# 2. 用户身份与 workspace 权限
|
||
|
||
用户身份确定谁在操作，资源归属确定操作的目标，权限确定允许进行哪些操作。平台用同一套身份与权限模型处理代码、基础内容和 agent；代码可视域另行决定声明在程序中的引用范围。
|
||
|
||
workspace 是资源的整体归属、协作和授权边界。namespace key 使用 workspace handle 定位这一边界，用户身份用于登录、判断操作权限和记录作者。`w` 表示编辑资源，`x` 表示使用已定义的程序能力，程序产生业务写入不要求调用者因此成为 Editor。
|
||
|
||
## 2.1 Workspace handle 与显示名
|
||
|
||
Workspace handle 是在平台内唯一定位 workspace 的名称，参与 namespace key。workspace 显示名用于界面展示，可以重复，不承担唯一定位职责。
|
||
|
||
| 属性 | Workspace handle | Workspace 显示名 |
|
||
| --- | --- | --- |
|
||
| 用途 | 唯一定位 workspace 及其 namespace | 面向用户展示名称 |
|
||
| 唯一性 | 在本平台内唯一 | 可以重复 |
|
||
| 参与 namespace key | 是 | 否 |
|
||
| 示例 | `atelier` | `工作室` |
|
||
|
||
两个 workspace 可以都叫“工作室”，但其 handle 必须不同。例如 atelier 和 market 是两个 workspace；即使它们的显示名相同，其资源也分别定位。
|
||
|
||
用户账号与 workspace 是不同对象。一个用户可以参与多个 workspace，一个 workspace 可以有多个用户；资源地址不使用当前用户、管理员或作者的名字作为归属前缀。用户的登录标识及展示名称不决定资源 key，其具体形式见[规范状态](../appendices/specification-status.md#身份与权限)。
|
||
|
||
## 2.2 key 中的 workspace 部分
|
||
|
||
namespace key 由 workspace handle 与非空 namespace 路径组成：
|
||
|
||
```text
|
||
workspace handle:namespace路径
|
||
atelier:shop.ui
|
||
```
|
||
|
||
冒号前的 `atelier` 是 workspace handle，不带 `@` 前缀；冒号后的 `shop.ui` 定位该 workspace 内的 namespace。
|
||
|
||
| key | 归属 workspace | namespace 路径 |
|
||
| --- | --- | --- |
|
||
| `atelier:shop` | `atelier` | `shop` |
|
||
| `market:shop` | `market` | `shop` |
|
||
| `atelier:shop.ui` | `atelier` | `shop.ui` |
|
||
|
||
`atelier:shop` 与 `market:shop` 是不同的 namespace，即使它们具有相同的路径或相同的代码内容。
|
||
|
||
只有 workspace handle 不能构成 namespace key。独立登记的资源还需要至少一级 namespace，完整格式见[namespace](03-namespaces.md)。workspace 本身的管理入口不由 namespace key 文法定义。
|
||
|
||
## 2.3 归属上下文
|
||
|
||
资源与 workspace 的归属通过代码之外的 key 与索引成员关系关联。读取、编辑和处理代码时，系统使用该归属上下文。
|
||
|
||
函数名、变量名、注释、字符串和存储对象名均不定义归属 workspace。两段内容相同的代码分别关联不同 workspace 时，其归属上下文仍然不同。
|
||
|
||
正文中的 `use atelier:shop.pricing` 表示引用目标，不表示当前代码属于 atelier。例如，`market:shop.checkout` 可以引用 atelier 的逻辑，其自身归属仍是 market。
|
||
|
||
## 2.4 归属 workspace、操作用户与作者
|
||
|
||
归属主体与用户身份承担不同职责：
|
||
|
||
| 身份 | 含义 | 关联对象 |
|
||
| --- | --- | --- |
|
||
| 归属 workspace | 资源位于哪个整体归属与授权范围 | namespace key 与资源成员关系 |
|
||
| 操作用户 | 谁发起读取、修改或执行 | 本次操作的身份上下文 |
|
||
| 作者或修改者 | 谁编写或修改了代码 | 编辑或历史记录 |
|
||
|
||
例如 alice 与 bob 同属 atelier，bob 修改 `atelier:shop` 的代码时，操作用户和修改者都是 bob，资源仍归属 atelier。退出成员关系或更换管理员不会把资源自动转移到某个用户的个人 workspace。
|
||
|
||
Agent 或服务代用户操作时同样需要区分操作身份与目标归属。协作、委托和历史记录的具体规则参见[规范状态](../appendices/specification-status.md#身份与权限)。
|
||
|
||
## 2.5 Workspace 与平台用户系统
|
||
|
||
workspace 是一组资源共同归属、协作和授权的整体，包含 namespace、函数、class、agent 及独立保存的基础内容。用户拥有自己的账号，可以创建 workspace，也可以加入其他 workspace；成员关系不改变用户身份。
|
||
|
||
注册时创建用户账号，同时创建一个默认个人 workspace，并将注册用户设为该 workspace 的管理员。个人 workspace 和多人 workspace 使用同一模型，差别在于成员数量及其角色；个人 workspace 也可以邀请其他用户加入。
|
||
|
||
平台可以限制每个用户创建 workspace 的数量。加入已有 workspace 与创建新 workspace 是不同操作，数量上限、计数归属和删除后的额度恢复规则待定。
|
||
|
||
| 概念 | 职责 | 是否随协作者变化而变化 |
|
||
| --- | --- | --- |
|
||
| 用户身份 | 认证操作用户、记录作者与修改者 | 每位用户独立存在 |
|
||
| workspace | 承担整体资源归属与权限边界 | 成员变动不改变资源归属 |
|
||
| workspace handle | 唯一定位 workspace | 改名与历史引用规则需单独定义 |
|
||
| namespace | 在归属范围内组织和检索资源 | 不因加入一名成员自动增加一层路径 |
|
||
|
||
同一 workspace 中可以包含多组 namespace，各组共享 workspace 的授权边界。成员与资源的关系示意如下：
|
||
|
||
```text
|
||
workspace：atelier
|
||
成员：alice、bob
|
||
|
||
atelier:shop.pricing
|
||
atelier:shop.data
|
||
atelier:shop.agents
|
||
```
|
||
|
||
alice 和 bob 编辑同一 workspace 的资源，作者记录各自的用户身份，资源仍归属 atelier。管理员变化或成员退出不要求重写 namespace 引用。默认 workspace 的 handle 如何生成、已有用户名 key 如何迁移，见[规范状态](../appendices/specification-status.md#workspace-名称与生命周期)。
|
||
|
||
## 2.6 r、w、x 的操作分工
|
||
|
||
三个权限字母表达资源操作的类别；具体角色及其授予范围在 2.7 的 workspace 模型中定义。
|
||
|
||
| 权限 | 允许的操作 | 不由该权限单独授予的能力 |
|
||
| --- | --- | --- |
|
||
| `r`：读取 | 浏览获准读取的代码、内容和资源视图 | 编辑资源、执行程序 |
|
||
| `w`：编辑 | 创建、修改、删除资源内容或代码定义 | 修改成员角色、扩大授权 |
|
||
| `x`：执行 | 调用已定义并允许外部使用的程序入口，取得契约允许的结果 | 任意改写实现源码或直接管理全部业务数据 |
|
||
|
||
`w` 与 `x` 的区别是编辑资源和使用程序。修改“提交订单”函数的定义需要 `w`；使用已经定义好的提交订单能力需要 `x`。该调用按业务契约保存订单，不要求调用用户获得函数源码的编辑权限。
|
||
|
||
同样，agent 在既定任务内执行获准业务操作与提交新的代码定义分别处理：使用 agent 的入口需要相应执行授权，向 namespace 保存或修改代码需要目标范围的 `w`。
|
||
|
||
程序的业务效果需要受定义好的操作范围、输入、业务条件及调用授权约束。`x` 不等于调用者获得管理员身份，也不表示能越过入口直接编辑任意资源。具体执行身份和运行能力如何关联仍待定义，不能用“有 x”推导出平台范围的无限授权。
|
||
|
||
读源码与使用软件可以分别授权。只有 `x` 的用户可以使用获准入口及调用所需的接口信息，而不因此获得完整实现源码的 `r`；接口信息的可见范围另行定义。读取函数不会自动运行它，执行后也只取得契约允许交付的结果。
|
||
|
||
高风险操作仍遵守[人工在环](13-agents.md#136-人工在环与中断)等既定执行条件。执行授权与人类确认承担不同职责。
|
||
|
||
## 2.7 Workspace 角色与授权
|
||
|
||
平台按 workspace 记录用户的角色，用角色提供常用权限组合。角色只在对应 workspace 生效，用户在一个 workspace 是管理员，不表示其在其他 workspace 也拥有管理能力。
|
||
|
||
| 角色或访问状态 | 权限基线 | 管理能力 |
|
||
| --- | --- | --- |
|
||
| 管理员 | `rwx` | 管理成员、角色及 workspace 设置 |
|
||
| Editor | `rwx` | 编辑和使用资源，不管理授权 |
|
||
| Reader | `r--` | 浏览资源，不修改资源 |
|
||
| 无访问权限 | `---` | 无 |
|
||
|
||
管理员与 Editor 的资源权限相同，但管理成员和授权属于管理员角色的管理能力，不增加第四个资源权限位。Editor 不能通过修改普通资源或编写函数为自己授予管理员角色。
|
||
|
||
Reader 是否附带 `x`，以及如何向不读源码的用户授予 `--x`，保留为 workspace 层面的共享与运行授权选择，不为每个函数增加一份独立权限表。未获得 `r` 与完全无访问权限是不同状态；执行用户可以具有 `x` 而不具有 `r`。
|
||
|
||
角色作用于整个 workspace 的资源，不为每个 namespace、class、字段或函数分别维护访问名单。需要不同协作和授权边界的资源放入不同 workspace，workspace 内通过 namespace 与代码可视域组织结构。
|
||
|
||
公开或未加入 workspace 的用户也不能仅凭 key 获得访问权。默认公开性、匿名访问以及运行授权的授予方式仍待定义。
|
||
|
||
## 2.8 权限边界与 namespace
|
||
|
||
workspace 是整体授权边界，namespace 是内部组织与检索范围。一个用户获得 workspace 的读取权限，可以在该范围内读取资源；读取某个 namespace 时包含哪些成员，仍由视图成员规则决定。
|
||
|
||
```text
|
||
用户在 workspace 中的角色与授权
|
||
→ 允许的 r、w、x 操作
|
||
→ 定位目标 namespace 与资源
|
||
→ 按该操作和资源契约使用
|
||
```
|
||
|
||
第一级和后续 namespace 层级具有相同语义，不在每层重新配置权限。权限适用整个 workspace 不等于每次读取父 namespace 都自动合并全部下级内容；授权范围与视图成员范围是两个维度。
|
||
|
||
namespace key 是定位信息，不是访问凭据。知道 workspace handle 或 key，不等于获得读取、修改或调用其中声明的权限。
|
||
|
||
## 2.9 平台权限与代码可视域
|
||
|
||
平台权限回答“这个操作用户能对目标资源做什么”，代码可视域回答“这个声明能否在当前代码位置被引用”。程序引用或调用需要分别满足对应的可视域与操作权限；查看实现源码则依据读取授权判断。
|
||
|
||
| 情况 | 需要判断的规则 |
|
||
| ------------- | ------------------ |
|
||
| 查看一个内部成员的源码 | 是否具有对应资源的读取权限 |
|
||
| 外部函数直接引用该内部成员 | 是否满足声明可见性和名称查找规则 |
|
||
| 导入并调用一个外部入口 | 是否可解析该入口，并具有对应执行授权 |
|
||
| 修改入口或内部成员实现 | 是否具有目标范围的编辑权限 |
|
||
|
||
允许阅读源码不自动允许外部代码引用全部内部成员；声明允许外部引用也不自动向所有平台用户授予权限。use 指定依赖来源，不产生授权。
|
||
|
||
可视域可以在 namespace、class 或 agent 等程序结构中定义，不要求为每个内部声明建立用户权限表。具体可见性关键字、默认可视域和跨 namespace 名称查找见[程序结构与导入](04-program-structure.md#44-名称引用)。
|
||
|
||
## 2.10 操作身份、作者与 Agent
|
||
|
||
归属主体是 workspace，操作用户和作者是用户身份。作者记录表达谁编写或修改资源，不决定本次操作的权限。
|
||
|
||
agent 声明位于哪个 workspace，不直接决定本次运行以谁的权限执行。agent 引用一段代码、由管理员编写，或作为某个 workspace 的成员资源存在，都不自动获得管理员的管理能力。
|
||
|
||
编辑操作检查目标范围的 `w`；入口调用检查对应的 `x` 及业务契约。跨 workspace 调用分别判断目标范围的执行授权。角色或授权信息不要求写进每个函数的参数，也不因 use 改变。
|
||
|
||
程序如何取得操作身份、业务执行能力的绑定和委托、agent 生成代码的提交接口，以及异步任务恢复时的授权检查，仍待定义。
|
||
|
||
## 2.11 名称比较与生命周期
|
||
|
||
创建、检索与改名必须使用一致的 workspace handle 相等判定。两个被判定为相同的 handle 不能同时指向不同 workspace。
|
||
|
||
workspace 显示名不参与 key，修改显示名不改变资源归属。handle 的变更涉及既有 key 与引用的定位；旧名称复用还涉及历史引用是否继续指向原 workspace。
|
||
|
||
workspace handle 的字符集合、大小写、Unicode 处理、改名、名称复用和归属转移的具体规则集中列于[规范状态](../appendices/specification-status.md#workspace-名称与生命周期)。本书示例使用简单的小写 handle 说明结构，不据此限定最终字符集。
|
||
|
||
管理员交接、成员移除、workspace 停用，以及账号注销后的资源保留仍需明确。成员变化与资源归属分开处理；新请求按当前授权判断，已经运行的调用、实例或任务如何受到授权变化影响另行定义。
|
||
|
||
## 2.12 外部模型参考
|
||
|
||
Linux 文件权限使用所有者、组及其他用户的读、写、执行位，提供了操作类别的参考；本章的 workspace 角色及 `x` 的程序入口语义由 Endorphin 自行定义。[Linux inode 权限说明](https://man7.org/linux/man-pages/man7/inode.7.html)
|
||
|
||
Notion 将 workspace 成员关系与页面共享关联起来，提供了协作身份的参考。Endorphin 使用 workspace 整体授权，内部 namespace 负责组织资源。[Notion 成员与访客说明](https://www.notion.com/help/add-members-admins-guests-and-groups)
|
||
|
||
[上一章：语言概览](01-overview.md) · [下一章：namespace](03-namespaces.md) · [目录](../README.md)
|