别慌，这种情况我之前也碰到过，咱们一步步拆解排查：

1. 先确认会话是否还在生效 #

如果这个共用账号在你设置is_active=False之前已经登录了，Django默认不会主动踢掉已登录用户——它只会在下次登录验证时检查is_active状态。你可以：

• 让曾经用这个账号登录的人手动退出浏览器，再尝试重新登录，看是否被拦截
• 直接去Django Admin的「Sessions」页面（前提是启用了django.contrib.sessions），找到该用户对应的会话记录并删除，强制让会话失效

2. 验证is_active确实被改成False了 #

有时候手动操作可能会有疏漏，比如选错用户或者没点保存。咱们用命令行确认最稳妥：
打开终端运行：

python manage.py shell

然后输入：

# 如果用了自定义用户模型，替换成你的模型类
from django.contrib.auth.models import User
shared_user = User.objects.get(username="你的共用账号名")
print(shared_user.is_active)

如果输出是True，说明之前的修改没生效，回去重新设置并保存；如果是False，继续往下查。

3. 检查是否用了自定义认证后端 #

如果项目里配置了非默认的AuthenticationBackend（看settings.AUTHENTICATION_BACKENDS），很可能是自定义后端漏掉了is_active的检查。

默认的ModelBackend会在认证时验证user.is_active，但自定义后端如果没加这个判断，就会允许禁用用户登录。打开你的认证后端代码，找到authenticate方法，确保有类似逻辑：

def authenticate(self, request, username=None, password=None, **kwargs):
    # ... 你的用户查询逻辑 ...
    if user.check_password(password) and user.is_active:  # 必须要有这步is_active检查
        return user

如果没有，加上这个判断就解决问题了。

4. 排查缓存导致的延迟 #

如果项目启用了Django缓存（比如Redis、Memcached或者本地缓存），用户信息可能被缓存了，导致is_active的变更没实时生效。你可以：

• 清除浏览器的缓存和Cookie，再测试登录
• 运行命令清空Django缓存：

python manage.py clearcache

• 临时注释掉settings.py里的缓存配置，测试是否还能登录

5. 检查是否有特殊的自定义逻辑 #

极少数情况下，项目里可能有自定义中间件或者修改了Admin登录视图，绕过了is_active的验证。比如有些中间件会强制让特定用户通过认证，或者自定义Admin视图没调用默认的校验逻辑。

你可以检查settings.MIDDLEWARE里的自定义中间件，看看有没有和用户认证相关的代码，或者确认Admin的登录视图是否被重载过。

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