Django自定义登录实现正确性、多用户适配及安全问题咨询

你当前的写法既存在逻辑bug，也有严重的安全隐患，完全不符合生产环境的规范要求：

• 逻辑bug：Admin_user.objects.get() 在查询不到匹配记录时会直接抛出 DoesNotExist 异常，根本不会走到你写的if user!=None分支，只要用户输入的账号或密码错误，接口就会直接返回500错误，不会返回你预期的"Not a User"。你目前觉得功能正常，只是测试时刚好都输入了存在的正确账号密码，没有覆盖错误场景。
• 致命安全风险：密码明文存储、明文比对。你直接拿用户提交的明文密码和数据库存储的密码做匹配，意味着数据库一旦泄露，所有用户的密码会直接泄露；同时你自己写的比对逻辑没有防时序攻击的处理，攻击者可以通过响应时间差异枚举正确密码。
• 无登录态维持：就算账号密码匹配成功，你也只是返回了一句成功提示，没有在服务端记录用户登录状态，后续接口根本无法识别用户身份、判断访问权限。
• 缺少基础安全防护：没有暴力破解防护、没有CSRF校验，很容易被恶意攻击。

你提到项目有5种用户类型，这完全不需要抛弃Django内置的认证体系。Django的认证框架设计上就支持扩展，自己从零实现认证逻辑很容易遗漏各种安全边界，内置框架已经把密码哈希加盐、会话管理、时序攻击防护、密码强度校验这些通用安全逻辑都处理完了，直接用的安全性远高于自己手写。

核心原则 #

不管你怎么设计用户模型，绝对不要明文存储密码，不要自己实现密码校验逻辑。

1. 密码存储必须使用哈希 #

不管你用哪种用户模型设计，用户注册、修改密码时，都要用Django自带的哈希工具生成密码哈希值再存库：

from django.contrib.auth.hashers import make_password
# 保存用户到数据库前，对明文密码做哈希
user.password = make_password(用户提交的明文密码)
user.save()

2. 多用户类型的两种成熟实现 #

你可以根据现有项目的开发进度选其中一种：

• 方案一（推荐，改动成本最低）：核心身份认证走Django内置User模型，5种用户类型通过一对一关联的Profile表区分。
  账号、密码、会话管理这些通用逻辑全部复用内置实现，不同用户类型的差异化字段、权限逻辑存在各自的Profile表中（比如管理员Profile、普通用户Profile等），和User模型做一对一关联。登录时统一用内置方法校验账号密码，校验通过后再判断用户关联的Profile类型，走不同的业务逻辑即可。
• 方案二（适合已经写了大半自定义用户表的场景）：自定义用户模型继承Django认证基类。
  让你自己的用户模型继承AbstractBaseUser和PermissionsMixin，在模型上加一个user_type字段存储5种用户类型的枚举值，这样既保留了你自己的用户表结构，又能完全复用Django内置的所有认证能力。

3. 规范的登录视图参考 #

from django.contrib.auth import authenticate, login
from django.views.decorators.http import require_POST
from django.http import HttpResponse

@require_POST # 自动拦截非POST请求，不需要自己写方法判断
def login_action(request):
    email = request.POST.get("email", "").strip()
    password = request.POST.get("password", "")
    if not email or not password:
        return HttpResponse("账号和密码不能为空", status=400)

    # 内置方法自动做密码哈希校验，自带时序攻击防护
    user = authenticate(request, username=email, password=password)
    if not user:
        return HttpResponse("账号或密码错误", status=401)
    
    # 内置login方法自动处理会话写入，后续请求可通过request.user直接获取当前登录用户
    login(request, user)

    # 根据用户类型返回不同结果
    if user.user_type == "admin":
        return HttpResponse("管理员登录成功")
    elif user.user_type == "staff":
        return HttpResponse("运营人员登录成功")
    # 剩余3种用户类型按需判断即可

额外注意事项 #

• 生产环境一定要给登录接口加请求频率限制，避免被暴力破解；
• 默认开启CSRF中间件防护，避免跨站请求伪造攻击；
• 不要在接口返回里区分“账号不存在”和“密码错误”，统一返回“账号或密码错误”，避免被攻击者枚举有效账号。

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