企业官网建设流程全解析

如何用脚本测试 Budibase 的 SCIM 用户与组配置（Provisioning）接口

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase

在把身份提供方（IdP）接入 Budibase 的 SCIM Provisioning 之前，你需要先确认两件事：Provisioning 地址和 Token 是否可用，以及用户（User）和组（Group）的创建、成员关联是否能正常落地。Budibase 仓库自带的scripts/dev/testScim.sh就是干这个的：它通过 Docker 容器调用/api/global/scim/v2接口，创建一条 SCIM 用户、一条 SCIM 组，并把用户加入该组，最后打印出资源 ID。配套的scripts/dev/testScimNuke.sh则用于清理这些测试产物。

前置条件

跑测试脚本前，需要满足以下条件（均来自仓库内的实现与脚本要求）：

• Docker：两个脚本都以docker run方式在alpine:3.20容器内执行 curl/jq 请求。

• Budibase 实例正在运行且可访问：脚本默认的SCIM_URL是http://host.docker.internal:10000/api/global/scim/v2，即宿主机上的 10000 端口。如果你的实例在别处（例如 https 域名或别的端口），用环境变量SCIM_URL覆盖。

• SCIM 功能已启用：在 Builder 中进入 Settings > Auth > SCIM，打开 Activated 开关并保存。该页面同时显示两项关键信息：

  • Provisioning URL：${platformUrl}/api/global/scim/v2
  • Provisioning Token：即脚本需要的SCIM_TOKEN

  页面对应的实现见 SCIM 设置页。

• 许可证包含相应特性：服务端路由（scim.ts）要求 SCIM 功能开启，且组相关端点（POST/GET/PATCH/DELETE/groups）额外受Feature.USER_GROUPS特性保护；接口还要求管理员（auth.adminOnly）。特性缺失时的表现见文末“排查”。

获取 Token 与配置环境变量

SCIM_TOKEN取自 Settings > Auth > SCIM 页面中的 Provisioning Token。两个脚本对它的查找逻辑一致（见 testScim.sh 开头）：

1. 如果已导出环境变量SCIM_TOKEN，直接使用；
2. 否则从仓库根目录的.env文件中读取SCIM_TOKEN=...这一行（自动剥掉首尾引号）；
3. 两者都没有时报错退出：SCIM_TOKEN is required. Copy the provisioning token from Settings > Auth > SCIM.

因此有两种方式提供 Token：

# 方式一：直接导出环境变量 export SCIM_TOKEN="你的ProvisioningToken" # 方式二：写入仓库根目录的 .env 文件 SCIM_TOKEN=你的ProvisioningToken

如果 Budibase 不是跑在宿主机 10000 端口，再额外设置：

export SCIM_URL="https://your-budibase-domain/api/global/scim/v2"

运行测试脚本：创建用户与组并验证

在仓库根目录执行：

bash scripts/dev/testScim.sh

脚本会启动一个一次性容器（docker run -i --rm，带--add-host=host.docker.internal:host-gateway，容器内安装 curl 和 jq），依次执行三个 SCIM 请求：

1. POST/users：创建一个用户，externalId为local-user-<时间戳>，userName为local.user.<时间戳>@example.com，并带上 enterprise User 扩展 schema；
2. POST/groups：创建一个组，externalId为local-group-<时间戳>，displayName为Local Azure Test Group <时间戳>，schema 中同时包含 core Group 和 Microsoft AD SCIM Group 扩展；
3. PATCH/groups/<group_id>：通过PatchOp的add操作把上一步创建的用户加入组的members。

成功时的输出（后缀为脚本生成的秒级时间戳，每次运行不同）：

Created SCIM user: <user_id> Created SCIM group: <group_id> Group display name: Local Azure Test Group 1757635200

user_id/group_id是接口返回的资源 ID，不是固定值。脚本使用set -euo pipefail且每个 curl 都带-fsS，任何一步请求失败（非 2xx 或网络错误）都会直接中断退出，因此只要看到上面两行Created输出，说明用户创建、组创建、成员关联三步都通过了。

还可以做一次人工复核：用同一个 Token 调列表接口，确认资源已持久化：

curl -s -H "Authorization: Bearer ${SCIM_TOKEN}" \ "http://host.docker.internal:10000/api/global/scim/v2/users"

返回体是 SCIM 标准 ListResponse（含Resources、totalResults、itemsPerPage等字段，参考 types 定义）。列表默认每页 20 条，可以用?startIndex=翻页，也可以按userName eq "..."、externalId eq "..."这类 filter 精确查找刚创建的测试用户（行为见 scim.spec.ts）。组列表同理支持displayName eq "..."过滤和excludedAttributes=members排除成员字段。

清理测试数据（可选）

测试会在实例里留下真实的 SCIM 用户和组。如果需要清理，使用配套的 testScimNuke.sh：

bash scripts/dev/testScimNuke.sh

注意副作用：这个脚本不是只删刚才创建的测试数据，而是删除全部SCIM-provisioned 资源——它先列出/groups下的所有 SCIM 组逐一 DELETE，再列出/users（全局用户接口）下所有scimInfo.isSync == true的用户逐一 DELETE。如果你的实例里已有 IdP 同步过来的正式用户，运行前务必确认这些数据可以被删除，否则不要执行。Token 的提供方式与测试脚本相同。执行过程中脚本会打印Found N SCIM groups、Deleted SCIM group: <id>之类的进度，全部删除成功时退出码为 0，有失败则退出码为 1 并在 stderr 打印Failed to delete ...。

另一种不依赖脚本的清理方式：在 Settings > Auth > SCIM 页面关闭 Activated 开关，Budibase 会要求你选择处理方式——“Remove SCIM users”（永久删除所有 SCIM 用户）或“Convert to regular users”（保留用户但不再与 IdP 同步）。

排查：请求失败时对照这些返回

结合服务端实现与 接口测试，几个典型失败现象和判断依据：

另外两点接口行为值得在测试中留意（来自接口测试用例）：对active发Replace操作置为false（值可以是false、"false"、"False"）会直接删除该用户，后续 GET 返回 404；删除账号持有者（account holder）会返回 400"Account holder cannot be deleted"。

下一步

脚本验证通过后，就可以把 Settings > Auth > SCIM 页面显示的 Provisioning URL 与 Provisioning Token 配置到你的身份提供方，由 IdP 侧发起真实的用户与组同步；如果组端点因许可证受限不可用，先确认USER_GROUPS特性已包含在许可证中，再执行 IdP 侧的组同步配置。

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase