Scalar 团队用户管理实战Teams、角色权限与访问控制的完整机制【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar本文基于 Scalar 官方文档 用户管理指南 展开系统讲解 Scalar 中团队Team作为顶层容器的组织模型、Owner/Admin/Editor 三级角色及其权限矩阵、成员邀请与管理的完整操作流程以及域名限制与 SSO/SAML 等企业级访问控制手段。读完本文你可以独立完成团队搭建、按职责分配角色、邀请与移除成员并结合开源仓库中的鉴权源码理解角色在 Scalar 应用内部是如何落地生效的。团队Scalar 中一切资源的归属单位在 Scalar 中所有资源都属于一个团队API 文档、Registry 中的 API、SDK、主题乃至账单都挂在团队之下你邀请到团队的人依据各自的**角色role**获得对这些资源的访问权限。一个团队包含什么每个团队具有以下核心属性名称name与 slugslug 是 URL 中使用的唯一标识符命名空间namespace供 Registry 使用用于隔离不同团队的 API 命名空间共享的计费套餐billing plan团队内所有成员共用同一个套餐成员列表members每位成员都带有一个角色。多团队归属与切换一个账号可以属于多个团队可以在 Settings 的团队切换器team switcher中在不同团队之间切换。这在按公司、客户或环境划分工作时很有用。需要特别注意的是成员、计费与项目从不跨团队共享——如果一个人需要访问两个团队必须被分别邀请进这两个团队。每个账号必须至少属于一个团队因此你不能删除自己唯一的团队。从源码结构可以印证团队是权限与令牌的作用域这一设计Scalar 桌面/网页应用projects/scalar-app在刷新访问令牌时会显式携带teamUid参数即POST /core/login/refresh { refreshToken: ..., teamUid: ... }参见 use-auth.ts 中的refreshTokens(teamUid?)实现。这意味着访问令牌是按团队签发的切换团队会触发针对目标团队的令牌刷新而不是复用原团队的令牌。这也解释了为什么成员与资源严格隔离在团队边界之内。角色与权限Scalar 使用三个角色。官方建议分配仍然能让对方完成工作的最低角色。角色适合谁能做什么Owner对账号负责的人Admin 能做的一切以及添加/移除其他 Owner、变更 Owner 角色、删除团队Admin团队负责人与 API 平台负责人邀请/移除成员、变更非 Owner 成员的角色、管理计费与套餐以及 Editor 能做的一切Editor写文档、发布 API 的每个人创建、编辑、删除文档、API、SDK 与主题同一信息以权限矩阵形式表达如下权限OwnerAdminEditor创建、编辑、删除文档与项目✅✅✅邀请和移除成员✅✅❌变更 Owner 以下角色的成员✅✅❌管理计费与套餐✅✅❌添加、移除或提升 Owner✅❌❌删除团队✅❌❌团队必须始终至少有一个 Owner。如果你是唯一的 Owner在移除自己或离开团队之前必须先提升其他人为 Owner。源码视角角色如何随令牌下发角色并非只在界面层面存在它被直接编码在鉴权令牌中。Scalar 应用定义了访问令牌 JWT 的负载结构schema.tsconst roleSchema union([literal(viewer), literal(editor), literal(owner), literal(admin)]) export const accessTokenPayloadSchema object({ userIndex: string({ typeComment: Internal user index used for lookups }), userUid: string({ typeComment: Unique identifier for the user }), teamUid: string({ typeComment: Unique identifier for the team }), email: string({ typeComment: Users email address }), role: roleSchema, exp: number({ typeComment: Token expiry time as a Unix timestamp }), })从源码结构看role字段与teamUid共同出现在每个访问令牌中——也就是说某人在某团队中的角色这一事实由令牌承载客户端每次解析令牌见 use-auth.ts 中的tokenData计算属性都会先按该 schema 做严格校验校验不通过即视为未登录。此外令牌中还存在一个viewer角色值作为兜底默认值这与后文访问者不需要团队席位的模型相一致。邀请成员邀请他人需要你是Owner 或 Admin进入仪表盘的Team Members页面点击Invite Member输入对方邮箱地址并选择一个角色点击Send Invite。被邀请者会收到一封带有加入团队链接的邮件。邀请链接有效期为三天如果邀请过期取消它并重新发送一份。尚未接受邀请的条目会以Invite Pending标记显示在成员列表中。要撤回邀请打开该邀请旁边的菜单并选择Cancel Invite。在付费套餐下每邀请一名成员都会增加一个计费席位billing seat移除成员则会相应释放一个席位。当前席位数量显示在成员列表上方。席位的含义可以在 定价文档 中得到佐证Free 套餐含 1 个 editor seatPro 含 5 个Business 含 10 个Enterprise 为自定义——因此邀请成员 占用席位在付费团队中直接关联到成本。管理成员所有成员管理都在仪表盘的Team Members页面完成。打开某人旁边的菜单可以Change role——在 Owner、Admin、Editor 之间调整其角色Remove from team——撤销其团队访问权限并释放其计费席位。Owner 在列表中单独分组展示以便随时看清谁最终对这个账号负责。移除成员不会删除其创建的任何内容——他们编写的文档、API 与 SDK 仍保留在团队中。主动离开团队如果你要自己离开某个团队前往User Settings页面在Danger Zone中选择Leave Team。注意如果你是该团队唯一的 Owner必须先让其他人成为 Owner否则团队将失去必需的 Owner。限制谁能加入域名限制与 SSO针对希望团队只限自己组织内部人员的需求Scalar 提供两个企业级控制域名限制Domain restrictions将邀请限制在你批准的邮箱域名内发往个人邮箱地址的邀请会在发出前被拒绝SSO/SAML将 Scalar 接入你的身份提供商IdP使访问遵循与公司其他系统相同的规则你还可以禁用密码登录使 SSO 成为唯一入口。按 用户管理文档 的表述这两项控制均位于 Enterprise 档位。需要说明的是定价页 的功能对比表对部分相关功能有更细的标注——例如 Email domain access control 自 Pro 起包含、SSO/SAML 自 Business 起包含、RBAC 仅 Enterprise 提供——实际可用范围请以最新的套餐页为准。SSO 接入本身并不复杂SSO/SAML 指南 给出了完整的六步流程在 IdP 中创建 SAML 应用、分配用户与组、在 Scalar 的 Team Security 页面启用 Single Sign-On 并创建连接、用 Scalar 提供的服务商信息Entity ID 为https://identity.scalar.com、ACS URL 为https://identity.scalar.com/acs配置 IdP、把 IdP 的登录 URL/Issuer/证书回填到 Scalar、最后启用令牌加密。Scalar 官方支持 Auth0、Google、Microsoft Entra ID、Okta、OneLogin、Ping Identity 等提供商。团队成员 vs. 访问组Access Groups这两个概念容易混淆值得精确区分团队成员Team members与你一起在 Scalar 仪表盘内构建产品的人属于本指南的覆盖范围需要占用席位访问组Access groups被允许阅读你私有文档的人。他们不需要团队席位也永远看不到仪表盘。实践建议是团队成员给同事用访问组给只需要读文档的客户和合作方用。访问组的落地方式在 私有文档指南 中有完整步骤在仪表盘左侧Access Groups下创建访问组往组里添加邮箱域名宽泛放行或具体邮箱精细控制然后在 Docs 项目的 Security 区域开启 Private Docs 并勾选该组。删除访问组后权限立即撤销。官方推荐实践文档末尾总结了若干被验证有效的做法保持 Owner 数量少但绝不少于一个两到三个通常最合适让团队负责人做 Admin这样他们处理邀请时无需等待 Owner新人默认给 Editor之后随时可以晋升在人员离职时复查成员列表或者接入 SSO 让离职offboarding自动生效。小结Scalar 的用户管理体系围绕三个层次组织团队是资源与计费的隔离边界角色Owner/Admin/Editor令牌层面另有 viewer 兜底决定成员能做什么访问组则把只读这一档需求从席位体系中剥离出来。配合域名限制与 SSO/SAML团队边界可以被锁定在组织内部。理解这套模型后你可以按最低可用角色原则完成授权、按席位成本管理邀请、并通过 Registry 指南、SSO 指南 与 定价页 深入各功能的配置细节。【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Scalar 团队用户管理实战：Teams、角色权限与访问控制的完整机制
Scalar 团队用户管理实战Teams、角色权限与访问控制的完整机制【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar本文基于 Scalar 官方文档 用户管理指南 展开系统讲解 Scalar 中团队Team作为顶层容器的组织模型、Owner/Admin/Editor 三级角色及其权限矩阵、成员邀请与管理的完整操作流程以及域名限制与 SSO/SAML 等企业级访问控制手段。读完本文你可以独立完成团队搭建、按职责分配角色、邀请与移除成员并结合开源仓库中的鉴权源码理解角色在 Scalar 应用内部是如何落地生效的。团队Scalar 中一切资源的归属单位在 Scalar 中所有资源都属于一个团队API 文档、Registry 中的 API、SDK、主题乃至账单都挂在团队之下你邀请到团队的人依据各自的**角色role**获得对这些资源的访问权限。一个团队包含什么每个团队具有以下核心属性名称name与 slugslug 是 URL 中使用的唯一标识符命名空间namespace供 Registry 使用用于隔离不同团队的 API 命名空间共享的计费套餐billing plan团队内所有成员共用同一个套餐成员列表members每位成员都带有一个角色。多团队归属与切换一个账号可以属于多个团队可以在 Settings 的团队切换器team switcher中在不同团队之间切换。这在按公司、客户或环境划分工作时很有用。需要特别注意的是成员、计费与项目从不跨团队共享——如果一个人需要访问两个团队必须被分别邀请进这两个团队。每个账号必须至少属于一个团队因此你不能删除自己唯一的团队。从源码结构可以印证团队是权限与令牌的作用域这一设计Scalar 桌面/网页应用projects/scalar-app在刷新访问令牌时会显式携带teamUid参数即POST /core/login/refresh { refreshToken: ..., teamUid: ... }参见 use-auth.ts 中的refreshTokens(teamUid?)实现。这意味着访问令牌是按团队签发的切换团队会触发针对目标团队的令牌刷新而不是复用原团队的令牌。这也解释了为什么成员与资源严格隔离在团队边界之内。角色与权限Scalar 使用三个角色。官方建议分配仍然能让对方完成工作的最低角色。角色适合谁能做什么Owner对账号负责的人Admin 能做的一切以及添加/移除其他 Owner、变更 Owner 角色、删除团队Admin团队负责人与 API 平台负责人邀请/移除成员、变更非 Owner 成员的角色、管理计费与套餐以及 Editor 能做的一切Editor写文档、发布 API 的每个人创建、编辑、删除文档、API、SDK 与主题同一信息以权限矩阵形式表达如下权限OwnerAdminEditor创建、编辑、删除文档与项目✅✅✅邀请和移除成员✅✅❌变更 Owner 以下角色的成员✅✅❌管理计费与套餐✅✅❌添加、移除或提升 Owner✅❌❌删除团队✅❌❌团队必须始终至少有一个 Owner。如果你是唯一的 Owner在移除自己或离开团队之前必须先提升其他人为 Owner。源码视角角色如何随令牌下发角色并非只在界面层面存在它被直接编码在鉴权令牌中。Scalar 应用定义了访问令牌 JWT 的负载结构schema.tsconst roleSchema union([literal(viewer), literal(editor), literal(owner), literal(admin)]) export const accessTokenPayloadSchema object({ userIndex: string({ typeComment: Internal user index used for lookups }), userUid: string({ typeComment: Unique identifier for the user }), teamUid: string({ typeComment: Unique identifier for the team }), email: string({ typeComment: Users email address }), role: roleSchema, exp: number({ typeComment: Token expiry time as a Unix timestamp }), })从源码结构看role字段与teamUid共同出现在每个访问令牌中——也就是说某人在某团队中的角色这一事实由令牌承载客户端每次解析令牌见 use-auth.ts 中的tokenData计算属性都会先按该 schema 做严格校验校验不通过即视为未登录。此外令牌中还存在一个viewer角色值作为兜底默认值这与后文访问者不需要团队席位的模型相一致。邀请成员邀请他人需要你是Owner 或 Admin进入仪表盘的Team Members页面点击Invite Member输入对方邮箱地址并选择一个角色点击Send Invite。被邀请者会收到一封带有加入团队链接的邮件。邀请链接有效期为三天如果邀请过期取消它并重新发送一份。尚未接受邀请的条目会以Invite Pending标记显示在成员列表中。要撤回邀请打开该邀请旁边的菜单并选择Cancel Invite。在付费套餐下每邀请一名成员都会增加一个计费席位billing seat移除成员则会相应释放一个席位。当前席位数量显示在成员列表上方。席位的含义可以在 定价文档 中得到佐证Free 套餐含 1 个 editor seatPro 含 5 个Business 含 10 个Enterprise 为自定义——因此邀请成员 占用席位在付费团队中直接关联到成本。管理成员所有成员管理都在仪表盘的Team Members页面完成。打开某人旁边的菜单可以Change role——在 Owner、Admin、Editor 之间调整其角色Remove from team——撤销其团队访问权限并释放其计费席位。Owner 在列表中单独分组展示以便随时看清谁最终对这个账号负责。移除成员不会删除其创建的任何内容——他们编写的文档、API 与 SDK 仍保留在团队中。主动离开团队如果你要自己离开某个团队前往User Settings页面在Danger Zone中选择Leave Team。注意如果你是该团队唯一的 Owner必须先让其他人成为 Owner否则团队将失去必需的 Owner。限制谁能加入域名限制与 SSO针对希望团队只限自己组织内部人员的需求Scalar 提供两个企业级控制域名限制Domain restrictions将邀请限制在你批准的邮箱域名内发往个人邮箱地址的邀请会在发出前被拒绝SSO/SAML将 Scalar 接入你的身份提供商IdP使访问遵循与公司其他系统相同的规则你还可以禁用密码登录使 SSO 成为唯一入口。按 用户管理文档 的表述这两项控制均位于 Enterprise 档位。需要说明的是定价页 的功能对比表对部分相关功能有更细的标注——例如 Email domain access control 自 Pro 起包含、SSO/SAML 自 Business 起包含、RBAC 仅 Enterprise 提供——实际可用范围请以最新的套餐页为准。SSO 接入本身并不复杂SSO/SAML 指南 给出了完整的六步流程在 IdP 中创建 SAML 应用、分配用户与组、在 Scalar 的 Team Security 页面启用 Single Sign-On 并创建连接、用 Scalar 提供的服务商信息Entity ID 为https://identity.scalar.com、ACS URL 为https://identity.scalar.com/acs配置 IdP、把 IdP 的登录 URL/Issuer/证书回填到 Scalar、最后启用令牌加密。Scalar 官方支持 Auth0、Google、Microsoft Entra ID、Okta、OneLogin、Ping Identity 等提供商。团队成员 vs. 访问组Access Groups这两个概念容易混淆值得精确区分团队成员Team members与你一起在 Scalar 仪表盘内构建产品的人属于本指南的覆盖范围需要占用席位访问组Access groups被允许阅读你私有文档的人。他们不需要团队席位也永远看不到仪表盘。实践建议是团队成员给同事用访问组给只需要读文档的客户和合作方用。访问组的落地方式在 私有文档指南 中有完整步骤在仪表盘左侧Access Groups下创建访问组往组里添加邮箱域名宽泛放行或具体邮箱精细控制然后在 Docs 项目的 Security 区域开启 Private Docs 并勾选该组。删除访问组后权限立即撤销。官方推荐实践文档末尾总结了若干被验证有效的做法保持 Owner 数量少但绝不少于一个两到三个通常最合适让团队负责人做 Admin这样他们处理邀请时无需等待 Owner新人默认给 Editor之后随时可以晋升在人员离职时复查成员列表或者接入 SSO 让离职offboarding自动生效。小结Scalar 的用户管理体系围绕三个层次组织团队是资源与计费的隔离边界角色Owner/Admin/Editor令牌层面另有 viewer 兜底决定成员能做什么访问组则把只读这一档需求从席位体系中剥离出来。配合域名限制与 SSO/SAML团队边界可以被锁定在组织内部。理解这套模型后你可以按最低可用角色原则完成授权、按席位成本管理邀请、并通过 Registry 指南、SSO 指南 与 定价页 深入各功能的配置细节。【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考