perms-system-server/internal/logic/user/createUserLogic.go

package user

import (
	"context"
	"database/sql"
	"errors"
	"regexp"
	"strings"
	"time"

	"perms-system-server/internal/consts"
	authHelper "perms-system-server/internal/logic/auth"
	"perms-system-server/internal/middleware"
	userModel "perms-system-server/internal/model/user"
	"perms-system-server/internal/response"
	"perms-system-server/internal/svc"
	"perms-system-server/internal/types"
	"perms-system-server/internal/util"

	"github.com/zeromicro/go-zero/core/logx"
	"github.com/zeromicro/go-zero/core/stores/sqlx"
	"golang.org/x/crypto/bcrypt"
)

var usernameRegexp = regexp.MustCompile(`^[a-zA-Z0-9_]{2,64}$`)

// 审计 L-R17-1：非超管创建用户名时保留下列前缀，避免"抢注 admin_<productCode>"这条 DoS 链 ——
// CreateProductLogic 的 auto-provision 把初始管理员用户名定为 `admin_<productCode>`，与 sys_user
// 上的 UNIQUE(username) 共用同一槽位；若 product ADMIN 预先以 CreateUser 接口建出 `admin_acme`
// 这类账号，超管将来创建 productCode=acme 的新产品时会撞 1062，`compensateCreatedRows` 回滚，
// 造成"新产品一直上线不了"的业务 DoS。把 `admin_` / `svc_` / `root_` / `sys_` 保留给 SuperAdmin
// 路径（SuperAdmin 仍可通过 CreateUser 走这些前缀；auto-provision 走 SysUserModel.InsertWithTx
// 不经本正则，因此不受影响）。
var reservedUsernamePrefixes = []string{"admin_", "svc_", "root_", "sys_"}

type CreateUserLogic struct {
	logx.Logger
	ctx    context.Context
	svcCtx *svc.ServiceContext
}

func NewCreateUserLogic(ctx context.Context, svcCtx *svc.ServiceContext) *CreateUserLogic {
	return &CreateUserLogic{
		Logger: logx.WithContext(ctx),
		ctx:    ctx,
		svcCtx: svcCtx,
	}
}

// CreateUser 创建用户。新建系统用户账号，可指定部门归属。超管或当前产品 ADMIN 可调用。
// 注意：产品 ADMIN 创建的用户为系统级用户，不自动加入任何产品，需通过 AddMember 接口手动关联。
func (l *CreateUserLogic) CreateUser(req *types.CreateUserReq) (resp *types.IdResp, err error) {
	productCode := middleware.GetProductCode(l.ctx)
	if err := authHelper.RequireProductAdminFor(l.ctx, productCode); err != nil {
		return nil, err
	}

	caller := middleware.GetUserDetails(l.ctx)
	if caller == nil {
		return nil, response.ErrUnauthorized("未登录")
	}

	if msg := util.ValidatePassword(req.Password); msg != "" {
		return nil, response.ErrBadRequest(msg)
	}
	if !usernameRegexp.MatchString(req.Username) {
		return nil, response.ErrBadRequest("用户名只能包含字母、数字和下划线，长度2-64个字符")
	}
	// 审计 L-R17-1：非超管不得以保留前缀创建用户，防止对 CreateProductLogic 的
	// admin_<productCode> 抢注 DoS。SuperAdmin 不受限，可继续创建运维类系统账号。
	if !caller.IsSuperAdmin {
		lowered := strings.ToLower(req.Username)
		for _, p := range reservedUsernamePrefixes {
			if strings.HasPrefix(lowered, p) {
				return nil, response.ErrBadRequest("用户名不能以 " + p + " 开头（该前缀为系统账号保留）")
			}
		}
	}
	if len(req.Nickname) > 64 {
		return nil, response.ErrBadRequest("昵称长度不能超过64个字符")
	}
	if len(req.Remark) > 255 {
		return nil, response.ErrBadRequest("备注长度不能超过255个字符")
	}

	if req.Email != "" && !util.IsValidEmail(req.Email) {
		return nil, response.ErrBadRequest("邮箱格式不正确")
	}
	if req.Phone != "" && !util.IsValidPhone(req.Phone) {
		return nil, response.ErrBadRequest("手机号格式不正确")
	}

	// 审计 M-N4：CreateUser 之前只校验部门存在，不校验 caller.DeptPath 是否覆盖目标部门，
	// 产品 ADMIN 因此可为任意部门（包括 DEV/运维等敏感部门）预埋 admin_* / ops_* 之类的关键
	// 用户名，等其他部门 ADMIN 触发 AddMember 时顺势被挂进产品，绕过了 AddMember 侧
	// CheckAddMemberAccess 的部门链防护。
	//
	// 对齐 AddMember / UpdateUser 的语义，按身份分层校验：
	//   - 超管：任意部门放行（包含 DeptId=0 这种"无部门"的历史语义，用于创建跨组织账号）；
	//   - 非超管调用方：必须显式指定部门（DeptId > 0），且目标部门 Path 必须以 caller.DeptPath
	//     作为前缀；DeptId=0 的 "无部门账号"仅限超管，防止非超管在部门树外开口。
	// 审计 L-R13-4：显式拒绝 deptId < 0。原先只区分 >0 / 0 / 非超管的 0 三态，负数会落入
	// "非超管被拦 → 超管直接写 sys_user.deptId = -1"的洞：超管可以构造出 loadDept
	// FindOne(-1) → ErrNotFound → 5xx degrade 的僵尸账号，在部门树里永远隐形。
	if req.DeptId < 0 {
		return nil, response.ErrBadRequest("部门ID必须为非负整数")
	}
	// 审计 H-R17-1：非超管分支必须指定部门——早在进入事务前就断言，避免把"必填校验失败"
	// 的请求浪费掉一次 bcrypt + tx 开锁。
	if req.DeptId <= 0 && !caller.IsSuperAdmin {
		return nil, response.ErrBadRequest("必须指定部门")
	}

	// 审计 H-R17-1：bcrypt.GenerateFromPassword 在事务外完成——bcrypt default cost 约 60~100ms，
	// 若放进事务体会把 sys_dept 的 S 锁持有时长拉高到 100ms+，阻塞并发 DeleteDept / UpdateDept
	// 的 X 锁，引发写放大。tx 内只做"锁 sys_dept → Insert sys_user"的纯 DB 动作。
	hashedPwd, err := bcrypt.GenerateFromPassword([]byte(req.Password), bcrypt.DefaultCost)
	if err != nil {
		return nil, err
	}

	now := time.Now().Unix()
	var result sql.Result
	// 审计 H-R17-1：CreateUser 的 Insert 历史上游离事务之外，仅在 tx 前做一次 cached `FindOne(deptId)`
	// 校验 sys_dept 存在与 Status；但 DeleteDept 已经用 `sys_dept FOR UPDATE` + `sys_user FOR SHARE`
	// 的 tx 串行化堵住了"既有用户 vs 删部门"竞态，**未来用户 vs 删部门**这一面仍然敞开：
	//   1. CreateUser 先拿到 dept 快照（可能是 cache stale / non-locking read）；
	//   2. 并发 DeleteDept 在两者间完成事务；
	//   3. CreateUser 的 non-tx Insert 把 deptId 指向已被删除的 sys_dept 行，产生 orphan user。
	// 修复口径与 DeleteDept 的事务相对——事务内 `FindOneForShareTx` 对 sys_dept[deptId] 取 S 锁，
	// DeleteDept 的 X 锁被阻塞直到本 tx 提交；反之 DeleteDept 若先行提交，本 tx 的 S 锁会读到
	// `sqlx.ErrNotFound`，干净地回 400 "部门不存在或已删除"，彻底关闭"未来用户 → 幽灵部门"的窗口。
	err = l.svcCtx.SysUserModel.TransactCtx(l.ctx, func(ctx context.Context, session sqlx.Session) error {
		if req.DeptId > 0 {
			newDept, derr := l.svcCtx.SysDeptModel.FindOneForShareTx(ctx, session, req.DeptId)
			if derr != nil {
				if errors.Is(derr, sqlx.ErrNotFound) {
					return response.ErrBadRequest("部门不存在或已删除")
				}
				return derr
			}
			if newDept.Status != consts.StatusEnabled {
				return response.ErrBadRequest("目标部门已停用")
			}
			// 审计 H-R14-1：镜像 UpdateUser 侧护栏，DEV 部门在 loadPerms 里等价于"加入任一产品
			// 即全权"，跨产品信任边界的权限升级（见 H-R14-1 攻击链）必须收敛给 SuperAdmin。
			// 虽然当前非超管的 DeptPath 前缀校验已经天然约束了这条路径（产品 ADMIN 的
			// caller.DeptPath 通常不覆盖 DEV 子树），但显式判断能锁死语义，防止未来有人
			// 调整 caller.DeptPath 归属后意外打开缺口。
			if newDept.DeptType == consts.DeptTypeDev && !caller.IsSuperAdmin {
				return response.ErrForbidden("仅超级管理员可将用户调入研发部门")
			}
			if !caller.IsSuperAdmin {
				if caller.DeptPath == "" {
					return response.ErrForbidden("您未归属任何部门，无权创建用户")
				}
				if !strings.HasPrefix(newDept.Path, caller.DeptPath) {
					return response.ErrForbidden("无权在非自己管辖的部门下创建用户")
				}
			}
		}

		res, ierr := l.svcCtx.SysUserModel.InsertWithTx(ctx, session, &userModel.SysUser{
			Username:           req.Username,
			Password:           string(hashedPwd),
			Nickname:           req.Nickname,
			// 审计 L-R17-2：显式赋 `sql.NullString{Valid: false}` 把 DB 列落为 NULL。Go 结构体
			// 零值本身也是 `{Valid:false, String:""}`，行为相同；但显式写出来锁住语义——后续如
			// 有人把 SysUser.Avatar 改成纯 string 时，这里会立刻产生类型编译错误，避免"零值依赖"
			// 静默降级为落 `''` 空串（与历史 NULL 行并存的脏数据状态）。
			Avatar:             sql.NullString{Valid: false},
			Email:              req.Email,
			Phone:              req.Phone,
			Remark:             req.Remark,
			DeptId:             req.DeptId,
			IsSuperAdmin:       consts.IsSuperAdminNo,
			// 管理员代填的初始密码默认要求首次登录必须修改，降低"管理员口头下发后长期不换、口令库泄露即广义失陷"的风险（见审计 L-1）。
			MustChangePassword: consts.MustChangePasswordYes,
			Status:             consts.StatusEnabled,
			CreateTime:         now,
			UpdateTime:         now,
		})
		if ierr != nil {
			return ierr
		}
		result = res
		return nil
	})
	if err != nil {
		if util.IsDuplicateEntryErr(err) {
			return nil, response.ErrConflict("用户名已存在")
		}
		return nil, err
	}

	id, _ := result.LastInsertId()
	// 审计 M-R18-4：超管走 deptId=0 分支创建"无部门账号"是合法但敏感路径——跳过了 S 锁 /
	// 部门链 / DeptType 这一整套事务内校验，也会在 checkDeptHierarchy 等下游检查里被
	// fail-close 拦成"幽灵账号"。沉淀一条 Infow 审计事件便于运维事后回捞"谁/何时/为哪条
	// userId 创建了无部门账号"。非超管分支前置已拦，不会命中此日志。
	if req.DeptId == 0 {
		l.Infow("create user without dept",
			logx.Field("audit", "create_user_no_dept"),
			logx.Field("callerUserId", caller.UserId),
			logx.Field("newUserId", id),
			logx.Field("username", req.Username),
		)
	}
	return &types.IdResp{Id: id}, nil
}