Skip to content

feat(auth): sys_user 批量导入接口 —— 导入用户的密码处理策略 #2758

Description

@baozhoutao

背景

sys_usermanagedBy:'better-auth' 对象,CRUD affordances 里 create/import/edit/delete 全 false(见 packages/spec/src/data/object.zod.tsCRUD_AFFORDANCE_DEFAULTS),所以 Console 列表没有「新增/导入」,平台通用导入向导对它也被禁用。目前批量建号只能靠脚本循环调 better-auth 单条接口。

诉求

提供 sys_user(身份对象)专用的批量导入接口,把 Excel/CSV 里的员工批量建成可登录账号。核心难点是导入用户的密码怎么处理

核心决策点:密码处理策略(必须先定)

导入的用户需要一份可登录凭据,四种策略,建议支持多种、按导入任务选:

  1. 无密码 + 首登引导(最安全,推荐默认)

  2. 管理员统一临时密码 + 强制改密

    • 导入时给一个(或每人随机生成的)临时密码,落 requirePasswordChange 标记,首登强制改。
    • 需要平台支持"强制改密"标记与拦截(当前是否有?待确认;better-auth 无内置 requirePasswordChange,可能要自研 before-hook)。
    • 临时密码的下发渠道(导出一次性 CSV?邮件?)要定,且绝不落日志
  3. 导入历史系统的预哈希密码(迁移场景)

    • 老系统迁移时希望用户沿用原密码。better-auth 默认 scrypt;要接受外部哈希需配置自定义 emailAndPassword.password.hash/verify(better-auth 支持自定义 hasher)。
    • 需支持声明哈希算法/参数;不同算法混存要能区分。复杂度最高,列为可选高级能力。
  4. 随机密码 + 不下发(仅占位,用户只能靠重置登录)—— 一般不单独用,作为 1/2 的兜底。

接口设计建议

  • 新增身份专用导入端点(如 POST /api/v1/auth/admin/import-users),而非放开 sys_user 的通用 import affordance——因为要走 better-auth 的建号/哈希管线,不能直接 insert。
  • 入参:rows[](email/username/name/role/...)、passwordStrategy(上面 1–4)、dryRunupsert(按 email/username 幂等)、可选 sendInvitation
  • 复用通用导入框架的能力:dryRun、逐行校验报告、异步 Job、导入审计(对齐 feat(import): 产品级列表导入(L0–L4:批量/dryRun、Upsert 改记录、导入模板、异步 Job、校验审计) #2504,避免重造)。
  • 安全:密码/哈希字段禁止进日志/审计明文;权限 gate(仅 manage_platform_settings 等);限流。
  • 幂等:重复导入按 email/username upsert,不产生重复账号(参考记忆:insert 种子无 predev 清库会重复的教训)。

决策点(需拍板)

影响面

相关

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions