Django中设置is_active为false后用户仍可登录的原因排查

这种情况我之前处理过好几次，咱们按优先级一步步排查：

1. 检查用户会话是否未失效 #

如果这个共用账号在你禁用它之前已经登录了后台，Django不会自动让已登录的会话失效——除非用户主动退出，或者会话达到过期时间。你可以：

• 让该账号的使用者手动退出一次，再尝试登录；
• 登录Django admin的**会话管理（Sessions）**页面，找到该用户对应的所有会话记录并删除。

2. 确认数据库中is_active字段确实已更新 #

有时候手动在admin修改后，可能因为事务未提交或缓存问题，数据库里的实际值并没有改变。你可以：

• 直接查询数据库的auth_user表（如果用了自定义用户模型就查对应的表）：

  SELECT username, is_active FROM auth_user WHERE username='你的共用账号名';
  

  确认is_active的值是0（False）。

3. 检查自定义认证后端是否忽略了is_active校验 #

很多Django项目会自定义认证后端（AUTHENTICATION_BACKENDS），如果后端的authenticate方法没有校验用户的is_active状态，就会导致禁用的用户仍能登录。

• 先看settings.py里的AUTHENTICATION_BACKENDS配置，找到自定义的后端类；
• 检查该类的authenticate方法，确保最后返回用户前做了校验：

  # 正确的写法应该包含is_active检查
  def authenticate(self, request, username=None, password=None, **kwargs):
      try:
          user = User.objects.get(username=username)
          if user.check_password(password) and user.is_active:  # 这里必须检查is_active
              return user
      except User.DoesNotExist:
          return None
  

  如果你的代码里没有user.is_active的判断，那就是问题所在。

4. 排查是否有自定义代码绕过了is_active校验 #

• 检查是否重写了Django admin的登录视图，或者有自定义的登录逻辑；
• 查看项目中的中间件、信号，有没有在登录过程中强制激活用户或者忽略is_active的判断；
• 如果该账号是超级用户（is_superuser=True），确认有没有代码对超级用户做了特殊处理，跳过了is_active的校验。

5. 排除缓存或第三方登录的影响 #

• 如果项目启用了缓存（比如Redis、Memcached），执行python manage.py clearcache清除缓存，避免缓存保留了旧的用户状态；
• 如果集成了SSO（单点登录）或第三方登录服务，需要同步在对应平台禁用该账号，因为Django的is_active可能无法控制第三方登录的权限。

内容的提问来源于stack exchange，提问作者fateme