Harbor 本地数据库模式用户自助注册DB Auth测试用例 1-01 的完整走查与源码实现剖析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本篇技术文章围绕 Harbor 用户管理测试用例tests/testcases/Group1-user-management/1-01-DB-user-registration.md展开完整复现“本地数据库认证模式auth_mode: db_auth下非管理员用户自助注册Sign Up”这一功能场景从测试环境与前置条件、7 步手工测试流程、非法输入校验清单到 Harbor 服务端注册鉴权、用户存在性检查、密码校验的源码级实现链路。读完后你既能按文档独立执行该测试用例也能理解背后db_auth与self_registration两个开关在源码中如何协同控制注册能力。测试用例目标与适用场景用例文件位于 1-01-DB-user-registration.md其官方目标Purpose描述为To verify that a non-admin user can register an account (signup) when users are managed locally by Harbor (DB mode).也就是说该用例验证的核心命题是当 Harbor 的用户体系完全由本地数据库托管而非 LDAP/UAA/OIDC 等外部身份源时普通访客可以在 Harbor 首页自行注册账号并用注册凭据完成 Web UI 登录与 Docker 客户端登录。这一点在源码中有直接印证。Harbor 定义了四种认证模式常量其中db_auth即本地数据库模式见 src/common/const.goconst ( DBAuth db_auth LDAPAuth ldap_auth UAAAuth uaa_auth HTTPAuth http_auth OIDCAuth oidc_auth )只有db_auth模式下用户数据落在本地 PostgreSQL 数据库用户自助注册才有意义其他模式下账号由外部身份提供方管理。测试环境与前置条件用例文档的 Environment 一节列出三条硬性前提测试执行前必须逐项确认Harbor 实例已运行并可访问需要一个完整部署的 Harbor包含 portal、core、数据库等组件且 Web UI 可正常打开认证模式为本地数据库auth_mode必须配置为db_auth用户数据存储在本地数据库。对应源码中common.DBAuth db_auth常量客户端主机一台安装了 Docker CLI 的 Linux 主机用于第 6 步的docker login验证。在此之上还有一个用例文档没有显式列出、但由源码决定测试能否成立的关键前置条件self_registration自助注册开关必须为 true。该配置项在 src/lib/config/metadata/metadatalist.go 中定义{Name: common.SelfRegistration, Scope: UserScope, Group: BasicGroup, EnvKey: SELF_REGISTRATION, DefaultValue: false, ItemType: BoolType{}, Editable: false, Description: Whether the Harbor instance supports self-registration. If its set to false, admin need to add user to the instance.},要点有三默认值为false。若实例未开启自助注册UI 首页不会出现可用的注册入口本用例第 1 步“点击 Sign Up”即无法进行因此执行用例前务必先确认该开关已打开环境变量键为SELF_REGISTRATION部署编排层可据此注入描述明确说明关闭自助注册后只能由管理员代为添加用户对应同目录下用例 1-09-admin-create-delete-user.md 的场景。读取该开关的统一入口在 src/lib/config/userconfig.go// SelfRegistration returns the enablement of self registration func SelfRegistration(ctx context.Context) (bool, error) { return DefaultMgr().Get(ctx, common.SelfRegistration).GetBool(), nil }测试步骤完整走查以下 7 步与用例文档一一对应每一步都标注了其在服务端对应的位置便于在测试失败时定位问题。步骤 1-2在首页点击 Sign Up 并填写注册信息在 Harbor 首页点击 “Sign Up”进入注册表单填写用户名、邮箱、密码及确认密码。注册表单提交前前端会先调用“用户存在性检查”接口实时校验用户名/邮箱是否已被占用。该检查的后端实现在 src/core/controllers/base.go 的UserExists// UserExists checks if user exists when user input value in sign in form. func (cc *CommonController) UserExists() { ctx : cc.Context() flag, err : config.SelfRegistration(ctx) if err ! nil { log.Errorf(Failed to get the status of self registration flag, error: %v, disabling user existence check, err) } securityCtx, ok : security.FromContext(ctx) isAdmin : ok securityCtx.IsSysAdmin() if !flag !isAdmin { cc.CustomAbort(http.StatusPreconditionFailed, self registration deactivated, only sysadmin can check user existence) } target : cc.GetString(target) value : cc.GetString(value) var query *q.Query switch target { case username: query q.New(q.KeyWords{Username: value}) case email: query q.New(q.KeyWords{Email: value}) } ... }可以看到用户名和邮箱两条查询路径都受self_registration开关控制——开关关闭且请求者非系统管理员时直接返回 412Precondition Failed。这正是“注册表单能实时提示用户名是否被占用”背后的机制。步骤 3-5用用户名、邮箱分别登录 UI第 3 步使用新注册用户的用户名登录 UI验证成功后登出第 5 步再次使用同一用户的邮箱登录 UI确认邮箱同样可用作登录凭据然后登出。DB 模式下的认证逻辑在 src/core/auth/db/db.go 中实现// Auth implements Authenticator interface to authenticate user against DB. type Auth struct { auth.DefaultAuthenticateHelper userMgr user.Manager } // Authenticate calls dao to authenticate user. func (d *Auth) Authenticate(ctx context.Context, m models.AuthModel) (*models.User, error) { u, err : d.userMgr.MatchLocalPassword(ctx, m.Principal, m.Password) if err ! nil { return nil, err } if u nil { return nil, auth.NewErrAuth(Invalid credentials) } return u, nil }关键点认证函数接收的是models.AuthModel.Principal登录主体即用户名或邮箱与密码交由userMgr.MatchLocalPassword在本地用户表中完成匹配匹配不到则统一返回Invalid credentials避免泄露“用户名不存在”与“密码错误”的差异。该认证器在包初始化时通过auth.Register(common.DBAuth, Auth{userMgr: user.New()})注册到认证工厂见 db.go当实例auth_mode为db_auth时被选中。从源码结构看用户名与邮箱两种主体走同一MatchLocalPassword匹配路径这正是步骤 3 与步骤 5 预期都能登录成功的底层原因。步骤 6Docker 客户端登录验证用户名与邮箱各验一次在装有 Docker CLI 的 Linux 主机上执行docker login harbor_host用例要求username 与 email 两种凭据都要验证通过原文verify both。Docker Registry V2 的登录最终同样落到 Harbor core 的认证中间件再经由当前认证模式此处即db_auth完成校验因此只要 UI 登录成功Docker 登录预期也应成功若此步失败应优先检查harbor_host的 TLS/证书配置与 443 端口可达性而非用户数据本身。步骤 7非法输入校验六类异常注册退出 UI 后注册第二个新用户依次输入非法值验证校验是否生效、错误提示是否合理。用例文档列出的六类非法输入为非法输入类型预期行为服务端对应校验点用户名与已有用户重复注册被拒绝提示已占用UserExists 按Username查询返回占用提示用户名长度过长拒绝并提示长度超限表单/后端字段长度校验邮箱格式错误拒绝并提示格式非法邮箱格式校验邮箱长度过长拒绝并提示长度超限字段长度校验密码不符合密码规则拒绝并提示规则要求见下文“密码与 Secret 规则”两次密码输入不一致拒绝并提示不匹配确认密码一致性校验预期结果Expected Outcome用例文档给出的预期结果共四条作为测试判定标准第 2 步成功创建新用户新用户可在步骤 3、5 分别用用户名、邮箱通过 UI 登录新用户可在步骤 6 用邮箱和用户名通过 Docker 客户端登录第 7 步的非法注册输入全部被拒绝且界面能展示正确的错误信息。源码纵深注册能力的三重闸门除了上述流程内联的校验点外Harbor 对“创建用户”这个动作设置了多层闸门理解它们有助于解释各类报错来源。闸门一认证模式必须为 db_authAPI 层创建用户的准入检查在 src/server/v2.0/handler/user.go 的requireCreatablefunc (u *usersAPI) requireCreatable(ctx context.Context) error { a, err : u.getAuth(ctx) ... if a ! common.DBAuth { return errors.ForbiddenError(nil).WithMessagef(creating local user is not allowed under auth mode: %s, a) }非db_auth模式LDAP/OIDC 等下创建本地用户直接返回 403。这与用例前提“auth_mode 必须为 db_auth”互为印证。闸门二self_registration 开关与会话校验requireCreatable的后半段user.go继续检查自助注册开关sr, err : config.SelfRegistration(ctx) ... accessErr : u.RequireSystemAccess(ctx, rbac.ActionCreate, rbac.ResourceUser) if !sr { return accessErr } if accessErr ! nil !lib.GetCarrySession(ctx) { return errors.ForbiddenError(nil).WithMessage(self-registration cannot be triggered via API) } return nil其语义分三层self_registrationfalse时创建用户需要系统级Create权限——即只有管理员能加人普通用户注册请求被拒self_registrationtrue且请求者本身无创建权限时还要求请求携带会话来自 UI 的注册表单提交防止绕过页面直接以匿名 API 方式批量刷用户系统管理员创建用户则不受自助注册开关限制。闸门三密码/Secret 复杂度规则Harbor 服务端对用户密码、随机生成的 CLI secret 等凭据统一执行复杂度规则见 requireValidSecretfunc requireValidSecret(in string) error { hasLower : regexp.MustCompile([a-z]) hasUpper : regexp.MustCompile([A-Z]) hasNumber : regexp.MustCompile([0-9]) if len(in) 8 len(in) 128 hasLower.MatchString(in) hasUpper.MatchString(in) hasNumber.MatchString(in) { return nil } return errors.BadRequestError(nil).WithMessage(the password or secret must be 8-128, inclusively, characters long with at least 1 uppercase letter, 1 lowercase letter and 1 number) }规则为长度 8–128含端点且至少包含 1 个大写字母、1 个小写字母、1 个数字。用例第 7 步中“password input does not compliant to password rule”一类非法输入触发的正是这类复杂度校验编写测试数据时可用“纯数字密码”“纯小写短密码”等样本快速命中该规则。辅助观测点systeminfo 与 exporter前端需要知道“是否显示 Sign Up 入口”答案来自系统信息接口src/controller/systeminfo/controller.go 在响应模型中输出SelfRegistration字段controller.go 处从配置读取并安全转换UI 据此决定是否展示注册按钮Prometheus exporter 同样暴露了这两个动态开关见 src/pkg/exporter/system_collector.go 中harbor_self_registration指标以及harbor_auth_mode排障时可直接curlmetrics 端点确认实例当前的auth_mode与self_registration值无需登录 UI。可能的干扰因素与排查建议用例文档的 “Possible Problems” 标注为 None即不存在已知的固有失败模式。但结合源码闸门实际执行时最常见的“看似 bug 实为配置”的场景有两个首页看不到 Sign Up 或点击无效果大概率是self_registration为默认的false见 metadatalist.go 的默认值定义。先用 systeminfo 接口或 exporter 指标确认开关状态再决定是否开启UI 登录成功但docker login失败认证链路相同均为 db.go 的Authenticate因此问题通常出在客户端到 Harbor 的网络/TLS 层面而非账号数据。小结与相关用例本用例完整覆盖了 Harbor 本地数据库认证模式下“注册 → UI 登录用户名/邮箱→ Docker 登录用户名/邮箱→ 非法输入拒绝”的闭环是验证db_auth与self_registration两个配置协同工作的基准用例。同组还有若干可衔接执行的用例共同构成用户管理测试组1-03-DB-user-update-password.mdDB 模式下修改密码1-04-DB-user-update-account-settings.md更新账户设置1-09-admin-create-delete-user.md管理员创建/删除用户对应self_registrationfalse时的唯一加人途径1-07-LDAP-mode-general.md作为对照了解非 DB 模式下认证行为的差异。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考