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

package user

import (
	"context"
	"errors"

	"perms-system-server/internal/consts"
	"perms-system-server/internal/loaders"
	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"

	"github.com/zeromicro/go-zero/core/logx"
)

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

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

// UpdateUserStatus 冻结/解冻用户。修改用户启用状态并递增 tokenVersion 使其令牌失效。不能修改自身或超管状态。
// 若状态未实际变更则不做任何写操作，避免不必要的 tokenVersion 递增踢用户下线。
//
// 审计 L-R17-6 · 解冻（Disabled → Enabled）也递增 tokenVersion 是**刻意**设计：
// sysUserModel.UpdateStatus 的底层 SQL 无条件 `SET tokenVersion = tokenVersion + 1`，不论方向。
// 两种方向的语义分别是：
//   - **Enabled → Disabled**（冻结）：签发层吊销，已签发的 access/refresh token 立刻失效——
//     jwtauthMiddleware 的 tokenVersion 比对会把 claims.tokenVersion < DB.tokenVersion 的请求
//     一票否决，与 UpdateMember 的 M-R15-1 /  ChangePassword 的 tokenVersion 契约完全对齐。
//   - **Disabled → Enabled**（解冻）：用户本来就因 Status!=Enabled 无法登录/刷新 token，再 +1
//     在业务层等价于空动作；但保留 +1 能覆盖一条极端路径——"冻结→Redis 缓存携带旧 tokenVersion
//     → 解冻瞬间" 的极短窗口里，若 UD 聚合缓存失效失败（Clean 走 best-effort），旧 access
//     token 可能在客户端还没到 exp 前凭残留 UD 复活；无条件 +1 让这条复活路径一并堵死。
//
// 因此：**不要**把 tokenVersion+1 改成"条件递增"（如仅在冻结时 +1），否则"冻结 → 短窗口
// 抖动 → 解冻" 这三步会让已经被踢下线的用户靠老 token 悄悄回来。安全语义上"解冻 +1"是刚好
// 对等的代价（用户反正得重新登录）。
func (l *UpdateUserStatusLogic) UpdateUserStatus(req *types.UpdateUserStatusReq) error {
	if req.Status != consts.StatusEnabled && req.Status != consts.StatusDisabled {
		return response.ErrBadRequest("状态值无效，仅支持 1(启用) 和 2(冻结)")
	}

	callerId := middleware.GetUserId(l.ctx)
	// ValidateStatusChange 内部已经 FindOne(targetUserId)，结果透传给 CheckManageAccess 和
	// 下方的 status 对比，避免单次请求内重复 3 次 FindOne（见审计 M-5）。
	user, err := authHelper.ValidateStatusChange(l.ctx, l.svcCtx, callerId, req.Id)
	if err != nil {
		return err
	}

	productCode := middleware.GetProductCode(l.ctx)
	if err := authHelper.CheckManageAccess(l.ctx, l.svcCtx, req.Id, productCode, authHelper.WithPrefetchedTarget(user)); err != nil {
		return err
	}

	if user.Status == req.Status {
		return nil
	}

	// 审计 L-N4：把 FindOne 拿到的 UpdateTime 作为乐观锁，避免两个 admin 并发冻结/解冻时
	// last-write-wins，被连续 +2 tokenVersion、刚解冻又被踢下线等现象。
	if err := l.svcCtx.SysUserModel.UpdateStatus(l.ctx, req.Id, user.Username, req.Status, user.UpdateTime); err != nil {
		if errors.Is(err, userModel.ErrUpdateConflict) {
			return response.ErrConflict("数据已被其他操作修改，请刷新后重试")
		}
		return err
	}

	// 审计 L-R13-5 方案 A：冻结/解冻变更会决定能否继续登录，缓存必须立刻失效，不能被请求 ctx
	// 取消拖进 TTL 窗口——否则"已冻结用户"靠残留 UD 还能再撑 5 分钟。
	cleanCtx, cancel := loaders.DetachCacheCleanCtx(l.ctx)
	defer cancel()
	l.svcCtx.UserDetailsLoader.Clean(cleanCtx, req.Id)
	return nil
}