Suitenumerique项目中用户登录逻辑的缺陷分析与修复

问题背景

在Suitenumerique项目的用户认证系统中，存在一个关于非活跃用户处理的逻辑缺陷。当用户账户被标记为非活跃状态（is_active=False）后，如果该用户再次尝试登录，系统会错误地创建一个新的用户记录，而不是阻止登录或返回原有用户对象。

问题现象

具体表现为：

1. 管理员将某个用户标记为非活跃状态（is_active=False）
2. 该用户尝试重新登录系统
3. 系统没有识别已有用户记录，而是创建了一个新的用户对象
4. 导致数据库中出现多个具有相同sub（用户唯一标识符）或email的用户记录

技术分析

问题的根源在于用户获取逻辑的实现方式。原代码中，get_or_create_user方法首先尝试获取现有用户，如果找不到则创建新用户。但在这个过程中，对非活跃用户的处理不够完善。

关键问题点：

1. 用户查询方法get_existing_user在找到非活跃用户时，没有将其返回给调用方
2. 系统将非活跃用户视为"不存在"，导致后续逻辑创建新用户
3. 缺乏对用户状态的验证环节

解决方案

修复方案主要包含以下改进：

1. 修改用户查询逻辑：确保无论用户是否活跃，都能正确返回用户对象
2. 添加状态验证：在获取用户对象后，显式检查is_active状态
3. 统一处理流程：将状态验证集中到认证流程中

核心代码变更包括：

def get_existing_user(self, sub, email):
    """获取现有用户（无论是否活跃）"""
    try:
        return User.objects.get(sub=sub)
    except User.DoesNotExist:
        if email and settings.OIDC_FALLBACK_TO_EMAIL_FOR_IDENTIFICATION:
            try:
                return User.objects.get(email=email)
            except User.DoesNotExist:
                pass
    return None

def get_or_create_user(self, access_token, id_token, payload):
    # 获取用户（可能为非活跃状态）
    user = self.get_existing_user(sub, email)
    
    # 显式检查用户状态
    if user and not user.is_active:
        raise SuspiciousOperation(_("用户%s已被禁用" % sub))
    
    # ...其余创建逻辑

技术影响

这一修复带来了以下积极影响：

1. 数据一致性：避免了重复用户的产生，确保sub和email字段的唯一性
2. 安全提升：正确阻止非活跃用户登录，符合安全最佳实践
3. 逻辑清晰：将用户状态验证集中处理，便于后续维护

最佳实践建议

基于此问题的解决，建议在类似系统中注意以下几点：

1. 用户状态验证应作为独立环节，在认证流程中显式处理
2. 查询方法应返回所有匹配记录，由调用方决定如何处理不同状态
3. 对于禁用用户，应考虑记录登录尝试等安全审计信息
4. 在用户创建前，应全面验证所有唯一性约束条件

此修复确保了用户管理系统的健壮性和安全性，为Suitenumerique项目的用户认证流程提供了更可靠的基础。