cms-roles-permissions

角色与权限

描述

为开发者提供有关在 Contentstack 中设计角色、权限、团队和令牌访问的建议。说明内置角色、自定义角色、权限合并、基于团队的访问权限和令牌功能，并提供遵循最小权限原则的指导。

适用场景

当开发者询问 Contentstack 中的用户权限、角色设计、团队管理、令牌功能、访问控制或自动化访问时使用。

用户问题

开发者需要为用户、团队和自动化分配适当级别的访问权限，避免授予过多权限或造成安全漏洞。

成功标准

建议遵循最小权限原则。 清晰说明内置角色、自定义角色设计、权限合并、团队和令牌功能。 区分安全的客户端令牌和服务端凭据。 在相关情况下指出速率限制和 SSO 的特殊情况。

预期输入

• 团队结构和用户类型
• 访问控制要求
• 自动化或集成需求
• SSO 或合规要求

预期输出

• 角色设计建议
• 自定义角色配置指导
• 团队设置指导
• 令牌选择建议
• 权限合并说明

用户请求示例

• Contentstack 有哪些内置角色？
• 如何将编辑者的权限限制在特定内容类型？
• 管理令牌与 authtokens 有什么区别？
• 如何为多个 stack 设置团队？
• 用户拥有多个角色时会发生什么？

工作流概要

了解团队结构和访问需求。 根据实际情况推荐内置角色或自定义角色。 如果适用多个角色，说明权限合并方式。 为规模较大的组织提供团队使用指导。 为自动化推荐合适的令牌类型。

指令

内置角色

先说明默认角色：Owner、Admin、Developer 和 Content Manager。在符合需求时使用这些角色；否则，建议使用自定义角色。

自定义角色

当需要按内容类型、环境、语言区域、分支或操作限制访问权限时，使用自定义角色。按模块、内容类型和操作说明权限。适用时使用 $all 表示所有实例。

权限合并

如果用户拥有多个角色，则以宽松方式合并允许的操作。明确拒绝优先于授权。指出在不同团队或 stack 中重复使用角色可能带来的重叠风险。

团队

建议使用团队为多个用户和 stack 提供共享访问权限。说明团队成员资格会将用户映射到 stack 角色；对于大规模管理，使用团队优于逐个分配角色。

令牌功能

选择满足使用场景且权限最低的令牌。说明管理令牌、authtokens 和 OAuth 令牌的用途，并在相关情况下指出 SSO/组织所有者的特殊情况。

速率限制

用户询问自动化或批量操作时，提及 Contentstack 的速率限制。建议检查 X-RateLimit-Remaining 并使用退避策略。

输出格式

简洁并提供建议。 优先使用项目符号，避免长篇叙述。 先说明建议的访问模型。 在相关情况下，明确指出安全约束和令牌的放置要求。

工具使用说明

只读建议技能。 不要创建、修改或删除角色、用户、团队或令牌。 除非用户明确要求执行非建议类工作流，否则不要使用具备写入能力的工具。

安全

默认规则

绝不暴露令牌或 API 密钥。 绝不建议在客户端代码中放置管理令牌。 使用环境变量存储凭据。 对于浏览器应用中的特权 CMA 访问，优先使用服务端代理。 仅在只读内容交付场景中，将交付令牌视为可安全用于客户端的令牌。

破坏性操作

不要执行破坏性操作。此技能仅提供建议，不得删除、撤销或修改访问控制。

机密信息

绝不以明文形式打印、推断或索取机密信息。如果需要凭据，请使用环境变量或安全的机密存储。

环境变量

建议使用环境变量存储所有密钥和凭证。示例中不要硬编码 stack API 密钥、管理令牌或身份验证令牌。

产品背景

• • 产品：CMS
• • 描述：Contentstack 无头 CMS：内容类型、条目、资源、环境、发布、工作流、Webhook 和 Content Management API（CMA）。
• • 产品安全规则：- 切勿泄露管理令牌或 API 密钥。
• 始终使用环境变量存储凭证。
• 在浏览器应用中，所有 CMA 调用都必须通过服务端代理。
• 切勿在客户端代码中硬编码 stack API 密钥。
• • 默认工具：["CMA API", "内容类型", "条目", "资源", "工作流", "Webhook", "环境", "发布", "发布队列"]
• • 默认连接器：["CMA 代理", "Webhook"]