Harbor LDAP 模式下非管理员用户多项目创建与分页功能验证指南【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor导读本文档对应 Harbor 仓库中的功能验证用例 2-13-LDAP-user-push-multiple-projects.md核心目的是验证在 LDAP/AD 认证模式下auth_modeldap_auth非管理员用户能否创建多个项目并验证项目列表的分页与搜索功能是否正常工作。读完本文你将掌握 LDAP 模式下多项目创建验证的完整环境准备、操作步骤与预期结果判定方法同时理解 Harbor 底层 LDAP 认证、项目公开性与分页查询的实现原理便于自行设计同类回归测试。一、测试目标与适用场景本用例归属于tests/testcases/Group2-image-management测试套件该套件系统性地覆盖了 Harbor 镜像管理领域的核心用户场景包括用例主题认证模式2-01创建项目DB本地数据库2-03创建多个项目DB2-11创建项目LDAP2-12推送多个镜像LDAP2-13本文创建多个项目LDAP2-14查看项目LDAP本用例与 2-03 的唯一区别在于用户来源2-03 中用户由 Harbor 本地数据库管理db_auth而本用例中用户数据存储在 LDAP/AD 服务器中ldap_auth。这决定了该用例的验证重点是LDAP 用户经 Harbor 认证上船onboard后其身份权限模型与本地用户完全一致应具备同等的项目创建能力。为什么要单独验证 LDAP 模式从 src/core/auth/ldap/ldap.go 的实现可以看到LDAP 用户登录时与本地用户有一个关键差异LDAP 用户通过绑定Bind方式在 LDAP 服务器上完成密码校验成功后 Harbor 会在本地数据库中插入一条虚拟用户记录以便将用户与项目、成员、角色等实体关联。这个流程由PostAuthenticate→OnBoardUser完成ldap.go 中的OnBoardUser会为 LDAP 用户生成随机密码并标记Comment from LDAP.密码本身不保存在本地库中。因此本用例本质上是在验证这条LDAP 校验 本地关联链路在创建项目、分页浏览、关键词搜索等操作下是否稳定可靠。二、环境准备Environment依据原文档执行本用例需要满足以下前提条件Harbor 实例正在运行且可访问。Harbor 配置为向 LDAP/AD 服务器进行认证即auth_mode设置为ldap_auth用户数据存储在 LDAP/AD 服务器中。一台安装了 Docker CLI 的 Linux 主机作为 Docker 客户端。至少一个非管理员用户本文以用户 A代称实际使用时应替换为更有意义的长名称。注与原文档保持一致LDAP 模式下该用例只要求至少一个非管理员用户即可完成多项目创建验证无需像 2-11 那样准备两个用户。2.1 认证模式常量的源码确认在 src/common/const.go 中可找到认证模式的常量定义LDAPAuth ldap_authHarbor 的认证助手通过auth.Register机制注册ldap.go 末尾的init()函数完成注册func init() { auth.Register(common.LDAPAuth, Auth{ userMgr: user.New(), }) }这意味着当系统配置auth_modeldap_auth时登录请求会路由到ldap.Auth实现使用 LDAP 服务器完成身份校验。2.2 LDAP 登录认证链路ldap.go 中的Authenticate方法描述了完整链路这也是本用例能执行的前提校验用户名非空加载系统 LDAP 配置并建立会话ldapCtl.Ctl.SessionSession.Open在 LDAP 中搜索用户SearchUser要求恰好命中一条记录否则分别报Not found an entry/Multiple entries found使用用户 DN 与密码向 LDAP 服务器执行 Bind 校验校验通过后将用户名、真实姓名、邮箱写入models.User从本地数据库同步SysAdminFlag并附加 LDAP 用户组信息含组管理员 DN 识别、ldap_group_search_filter配置的组成员填充返回用户模型交由后续的PostAuthenticate完成 onboard。值得注意的细节attachLDAPGroup中会判断该用户所属组是否等于配置的group_admin_dn若命中则设置AdminRoleInAuth true——这也是 LDAP 模式下组管理员与系统管理员角色识别的关键逻辑。若 LDAP 组搜索过滤器为空则跳过组填充不会阻塞用户登录。三、测试步骤Test Steps原文档指出操作步骤与 2-03 相同仅用户来自 LDAP/AD。为便于独立执行下面将 2-03-DB-user-push-multiple-projects.md 的完整步骤迁移到 LDAP 场景并补充验证要点以非管理员用户 A 登录 Harbor UI用户 A 必须来自 LDAP/AD且通过 LDAP 认证成功 onboard。创建 16 个或更多项目使项目列表出现多页分页。创建项目时可采用默认配置公开性关闭即私有项目。在多页列表间翻页浏览并点开若干项目查看详情验证分页控件工作正常。使用关键词搜索项目验证列表与分页是否随搜索结果同步更新。原文提示文中的用户 A项目 X/Y等占位名称实际执行时应替换为更长、更有辨识度的名称避免与真实数据混淆。3.1 步骤要点解析步骤 2 的关键在于量只有项目数量超过单页容量Harbor 项目列表 API 默认按page/page_size参数分页才会出现多页因此要求创建 16 个以上项目以覆盖至少两页。这一步同时验证了 LDAP 用户连续创建多个项目的权限与配额是否正常。步骤 4 的关键在于搜索与分页联动输入关键词后列表应只展示匹配项目且分页总页数应基于过滤后的总数重新计算——这要求服务端先按关键词过滤、再分页返回而不是在前端做简单过滤。3.2 使用 REST API 辅助验证可选除了 UI 操作还可以通过 Harbor v2.0 API 直接验证分页与搜索行为。项目列表接口对应的服务端实现位于 src/server/v2.0/handler/project.go其关键调用链为query, err : a.BuildQuery(ctx, params.Q, params.Sort, params.Page, params.PageSize) ... WithLink(a.Links(ctx, params.HTTPRequest.URL, total, query.PageNumber, query.PageSize).String()).对应可构造如下请求# 不带筛选看第 1 页每页 10 条 curl -u userA:password \ https://harbor_host/api/v2.0/projects?page1page_size10 # 按关键词过滤同时观察分页 curl -u userA:password \ https://harbor_host/api/v2.0/projects?qname~keywordpage1page_size10其中q参数的模糊匹配语法name~keyword来自 src/lib/q/builder.go该文件定义了完整的查询语法精确匹配kv、模糊匹配k~v、区间k[min~max]、或列表k{v1 v2 v3}、与列表k(v1 v2 v3)。四、预期结果Expected Outcome与原文档及 2-03 一致本用例的预期结果如下步骤 3分页控件正常工作LDAP 用户 A 可以在多页之间自由翻页点开各项目详情均可正常查看步骤 4关键词搜索后列表与分页同步更新仅显示匹配搜索条件的项目且分页总数基于过滤结果正确计算。也就是说LDAP 模式下的非管理员用户应拥有与 DB 模式用户完全一致的多项目创建、浏览与搜索能力。五、源码级原理这些行为在 Harbor 中如何实现5.1 项目创建与公开性Publicity项目模型定义在 src/pkg/project/models/project.go其中项目公开性通过元数据键public存储常量ProjectPublic/ProjectPrivate分别对应public/privateIsPublic()读取public元数据并判断是否为 true字符串true或1均视为 trueFilterByPublic通过子查询SELECT project_id FROM project_metadata WHERE name public AND value ...实现公开项目过滤。项目控制器 src/controller/project/controller.go 对外暴露Create、List、Count、ListRoles等操作其中ListRoles用于查询用户在某项目中的角色非管理员用户创建项目后会自动成为该项目管理员项目所有者。5.2 分页与排序的实现Harbor 的统一分页机制位于 src/lib/q/builder.go 的Build函数// Build query sting, sort and pagination information into the Query model // query string format: qkv,k~v,k[min~max],k{v1 v2 v3},k(v1 v2 v3) func Build(q, sort string, pageNumber, pageSize int64) (*Query, error)它将查询串、排序串、页码与页大小统一封装为Query模型含Keywords、Sorts、PageNumber、PageSize。排序语法支持sortk1,-k2前缀-表示降序。服务端处理器通过 src/server/v2.0/handler/base.go 中的BuildQuery组装查询并用Links方法基于总数、页码、页大小生成上一页/下一页的导航链接——这正是 UI 分页控件的数据来源// BuildQuery builds the query model according to the query string func (b *BaseAPI) BuildQuery(_ context.Context, query, sort *string, pageNumber, pageSize *int64) (*q.Query, error) { ... return q.Build(qs, st, pn, ps) }结合 src/server/v2.0/handler/project.go 的调用点第 318、346 行等可以确认项目列表 API 先过滤q、再排序sort、后分页page/page_size并基于总数生成分页链接。这从底层印证了关键词搜索后分页同步更新的预期行为是服务端语义而非前端实现。5.3 LDAP 用户与本地权限模型的统一本用例之所以能与 DB 模式用例共用步骤其根本原因在于LDAP 用户登录成功后Harbor 通过OnBoardUser在本地用户表中建立映射记录密码为随机字符串、备注from LDAP.后续所有权限判断项目创建、成员关系、角色分配均基于本地用户 ID 进行。因此从项目控制器的视角看LDAP 用户与 DB 用户没有区别——这正是测试套件中 DB 用例与 LDAP 用例成对出现、步骤互引的设计动机。六、常见问题与排查建议原文档Possible Problems一节为空None但根据源码可以预判并排查以下潜在问题现象可能原因排查方向用户无法登录LDAP 配置错误、搜索命中多条记录检查ldap_url、ldap_base_dn、ldap_uid配置查看 ldap.go 中Authenticate对多条记录的报错登录成功但无法创建项目系统配置中限制了普通用户创建项目如project_creation_restriction或用户未被正确 onboard确认系统设置中的项目创建权限检查用户表中是否存在Comment from LDAP.的映射记录分页/搜索结果与预期不符服务端q参数语法错误参照 src/lib/q/builder.go 的语法规则构造查询LDAP 用户被识别为系统管理员用户属于group_admin_dn配置的组AdminRoleInAuth被置为 true检查attachLDAPGroup逻辑与组管理员配置七、结语本用例以极简的方式验证了一个关键的产品承诺无论用户来自本地数据库还是 LDAP/ADHarbor 都向非管理员用户提供一致的多项目创建、分页浏览与搜索能力。它作为 Group2 镜像管理测试套件中 LDAP 链路的一环与 2-11创建单个项目、2-12推送多个镜像、2-14查看项目共同构成了 LDAP 模式下镜像管理主链路的完整回归覆盖。测试人员可将本文步骤作为模板结合自身 LDAP 目录结构扩展更多项目数量与搜索关键词以覆盖边界场景。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor LDAP 模式下非管理员用户多项目创建与分页功能验证指南
Harbor LDAP 模式下非管理员用户多项目创建与分页功能验证指南【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor导读本文档对应 Harbor 仓库中的功能验证用例 2-13-LDAP-user-push-multiple-projects.md核心目的是验证在 LDAP/AD 认证模式下auth_modeldap_auth非管理员用户能否创建多个项目并验证项目列表的分页与搜索功能是否正常工作。读完本文你将掌握 LDAP 模式下多项目创建验证的完整环境准备、操作步骤与预期结果判定方法同时理解 Harbor 底层 LDAP 认证、项目公开性与分页查询的实现原理便于自行设计同类回归测试。一、测试目标与适用场景本用例归属于tests/testcases/Group2-image-management测试套件该套件系统性地覆盖了 Harbor 镜像管理领域的核心用户场景包括用例主题认证模式2-01创建项目DB本地数据库2-03创建多个项目DB2-11创建项目LDAP2-12推送多个镜像LDAP2-13本文创建多个项目LDAP2-14查看项目LDAP本用例与 2-03 的唯一区别在于用户来源2-03 中用户由 Harbor 本地数据库管理db_auth而本用例中用户数据存储在 LDAP/AD 服务器中ldap_auth。这决定了该用例的验证重点是LDAP 用户经 Harbor 认证上船onboard后其身份权限模型与本地用户完全一致应具备同等的项目创建能力。为什么要单独验证 LDAP 模式从 src/core/auth/ldap/ldap.go 的实现可以看到LDAP 用户登录时与本地用户有一个关键差异LDAP 用户通过绑定Bind方式在 LDAP 服务器上完成密码校验成功后 Harbor 会在本地数据库中插入一条虚拟用户记录以便将用户与项目、成员、角色等实体关联。这个流程由PostAuthenticate→OnBoardUser完成ldap.go 中的OnBoardUser会为 LDAP 用户生成随机密码并标记Comment from LDAP.密码本身不保存在本地库中。因此本用例本质上是在验证这条LDAP 校验 本地关联链路在创建项目、分页浏览、关键词搜索等操作下是否稳定可靠。二、环境准备Environment依据原文档执行本用例需要满足以下前提条件Harbor 实例正在运行且可访问。Harbor 配置为向 LDAP/AD 服务器进行认证即auth_mode设置为ldap_auth用户数据存储在 LDAP/AD 服务器中。一台安装了 Docker CLI 的 Linux 主机作为 Docker 客户端。至少一个非管理员用户本文以用户 A代称实际使用时应替换为更有意义的长名称。注与原文档保持一致LDAP 模式下该用例只要求至少一个非管理员用户即可完成多项目创建验证无需像 2-11 那样准备两个用户。2.1 认证模式常量的源码确认在 src/common/const.go 中可找到认证模式的常量定义LDAPAuth ldap_authHarbor 的认证助手通过auth.Register机制注册ldap.go 末尾的init()函数完成注册func init() { auth.Register(common.LDAPAuth, Auth{ userMgr: user.New(), }) }这意味着当系统配置auth_modeldap_auth时登录请求会路由到ldap.Auth实现使用 LDAP 服务器完成身份校验。2.2 LDAP 登录认证链路ldap.go 中的Authenticate方法描述了完整链路这也是本用例能执行的前提校验用户名非空加载系统 LDAP 配置并建立会话ldapCtl.Ctl.SessionSession.Open在 LDAP 中搜索用户SearchUser要求恰好命中一条记录否则分别报Not found an entry/Multiple entries found使用用户 DN 与密码向 LDAP 服务器执行 Bind 校验校验通过后将用户名、真实姓名、邮箱写入models.User从本地数据库同步SysAdminFlag并附加 LDAP 用户组信息含组管理员 DN 识别、ldap_group_search_filter配置的组成员填充返回用户模型交由后续的PostAuthenticate完成 onboard。值得注意的细节attachLDAPGroup中会判断该用户所属组是否等于配置的group_admin_dn若命中则设置AdminRoleInAuth true——这也是 LDAP 模式下组管理员与系统管理员角色识别的关键逻辑。若 LDAP 组搜索过滤器为空则跳过组填充不会阻塞用户登录。三、测试步骤Test Steps原文档指出操作步骤与 2-03 相同仅用户来自 LDAP/AD。为便于独立执行下面将 2-03-DB-user-push-multiple-projects.md 的完整步骤迁移到 LDAP 场景并补充验证要点以非管理员用户 A 登录 Harbor UI用户 A 必须来自 LDAP/AD且通过 LDAP 认证成功 onboard。创建 16 个或更多项目使项目列表出现多页分页。创建项目时可采用默认配置公开性关闭即私有项目。在多页列表间翻页浏览并点开若干项目查看详情验证分页控件工作正常。使用关键词搜索项目验证列表与分页是否随搜索结果同步更新。原文提示文中的用户 A项目 X/Y等占位名称实际执行时应替换为更长、更有辨识度的名称避免与真实数据混淆。3.1 步骤要点解析步骤 2 的关键在于量只有项目数量超过单页容量Harbor 项目列表 API 默认按page/page_size参数分页才会出现多页因此要求创建 16 个以上项目以覆盖至少两页。这一步同时验证了 LDAP 用户连续创建多个项目的权限与配额是否正常。步骤 4 的关键在于搜索与分页联动输入关键词后列表应只展示匹配项目且分页总页数应基于过滤后的总数重新计算——这要求服务端先按关键词过滤、再分页返回而不是在前端做简单过滤。3.2 使用 REST API 辅助验证可选除了 UI 操作还可以通过 Harbor v2.0 API 直接验证分页与搜索行为。项目列表接口对应的服务端实现位于 src/server/v2.0/handler/project.go其关键调用链为query, err : a.BuildQuery(ctx, params.Q, params.Sort, params.Page, params.PageSize) ... WithLink(a.Links(ctx, params.HTTPRequest.URL, total, query.PageNumber, query.PageSize).String()).对应可构造如下请求# 不带筛选看第 1 页每页 10 条 curl -u userA:password \ https://harbor_host/api/v2.0/projects?page1page_size10 # 按关键词过滤同时观察分页 curl -u userA:password \ https://harbor_host/api/v2.0/projects?qname~keywordpage1page_size10其中q参数的模糊匹配语法name~keyword来自 src/lib/q/builder.go该文件定义了完整的查询语法精确匹配kv、模糊匹配k~v、区间k[min~max]、或列表k{v1 v2 v3}、与列表k(v1 v2 v3)。四、预期结果Expected Outcome与原文档及 2-03 一致本用例的预期结果如下步骤 3分页控件正常工作LDAP 用户 A 可以在多页之间自由翻页点开各项目详情均可正常查看步骤 4关键词搜索后列表与分页同步更新仅显示匹配搜索条件的项目且分页总数基于过滤结果正确计算。也就是说LDAP 模式下的非管理员用户应拥有与 DB 模式用户完全一致的多项目创建、浏览与搜索能力。五、源码级原理这些行为在 Harbor 中如何实现5.1 项目创建与公开性Publicity项目模型定义在 src/pkg/project/models/project.go其中项目公开性通过元数据键public存储常量ProjectPublic/ProjectPrivate分别对应public/privateIsPublic()读取public元数据并判断是否为 true字符串true或1均视为 trueFilterByPublic通过子查询SELECT project_id FROM project_metadata WHERE name public AND value ...实现公开项目过滤。项目控制器 src/controller/project/controller.go 对外暴露Create、List、Count、ListRoles等操作其中ListRoles用于查询用户在某项目中的角色非管理员用户创建项目后会自动成为该项目管理员项目所有者。5.2 分页与排序的实现Harbor 的统一分页机制位于 src/lib/q/builder.go 的Build函数// Build query sting, sort and pagination information into the Query model // query string format: qkv,k~v,k[min~max],k{v1 v2 v3},k(v1 v2 v3) func Build(q, sort string, pageNumber, pageSize int64) (*Query, error)它将查询串、排序串、页码与页大小统一封装为Query模型含Keywords、Sorts、PageNumber、PageSize。排序语法支持sortk1,-k2前缀-表示降序。服务端处理器通过 src/server/v2.0/handler/base.go 中的BuildQuery组装查询并用Links方法基于总数、页码、页大小生成上一页/下一页的导航链接——这正是 UI 分页控件的数据来源// BuildQuery builds the query model according to the query string func (b *BaseAPI) BuildQuery(_ context.Context, query, sort *string, pageNumber, pageSize *int64) (*q.Query, error) { ... return q.Build(qs, st, pn, ps) }结合 src/server/v2.0/handler/project.go 的调用点第 318、346 行等可以确认项目列表 API 先过滤q、再排序sort、后分页page/page_size并基于总数生成分页链接。这从底层印证了关键词搜索后分页同步更新的预期行为是服务端语义而非前端实现。5.3 LDAP 用户与本地权限模型的统一本用例之所以能与 DB 模式用例共用步骤其根本原因在于LDAP 用户登录成功后Harbor 通过OnBoardUser在本地用户表中建立映射记录密码为随机字符串、备注from LDAP.后续所有权限判断项目创建、成员关系、角色分配均基于本地用户 ID 进行。因此从项目控制器的视角看LDAP 用户与 DB 用户没有区别——这正是测试套件中 DB 用例与 LDAP 用例成对出现、步骤互引的设计动机。六、常见问题与排查建议原文档Possible Problems一节为空None但根据源码可以预判并排查以下潜在问题现象可能原因排查方向用户无法登录LDAP 配置错误、搜索命中多条记录检查ldap_url、ldap_base_dn、ldap_uid配置查看 ldap.go 中Authenticate对多条记录的报错登录成功但无法创建项目系统配置中限制了普通用户创建项目如project_creation_restriction或用户未被正确 onboard确认系统设置中的项目创建权限检查用户表中是否存在Comment from LDAP.的映射记录分页/搜索结果与预期不符服务端q参数语法错误参照 src/lib/q/builder.go 的语法规则构造查询LDAP 用户被识别为系统管理员用户属于group_admin_dn配置的组AdminRoleInAuth被置为 true检查attachLDAPGroup逻辑与组管理员配置七、结语本用例以极简的方式验证了一个关键的产品承诺无论用户来自本地数据库还是 LDAP/ADHarbor 都向非管理员用户提供一致的多项目创建、分页浏览与搜索能力。它作为 Group2 镜像管理测试套件中 LDAP 链路的一环与 2-11创建单个项目、2-12推送多个镜像、2-14查看项目共同构成了 LDAP 模式下镜像管理主链路的完整回归覆盖。测试人员可将本文步骤作为模板结合自身 LDAP 目录结构扩展更多项目数量与搜索关键词以覆盖边界场景。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考