本文深入探讨了在django中实现自定义用户模型时，超级用户无法登录admin面板的常见问题。通过分析`abstractbaseuser`和`permissionsmixin`的内部机制，指出了因重复定义密码字段和验证方法导致的冲突。文章提供了正确的模型实现方式，强调了利用django内置认证功能的重要性，确保自定义用户模型能够安全、高效地与admin系统集成。
Django提供了一个强大的内置用户模型，但在许多实际应用中，开发者可能需要根据业务需求扩展或替换它。例如，使用电子邮件而非用户名作为主要认证凭据，或者添加额外的用户属性。Django通过AUTH_USER_MODEL设置和AbstractBaseUser、PermissionsMixin等基类，为自定义用户模型提供了灵活的框架。然而，不正确的实现方式可能导致一系列问题，其中最常见的就是超级用户无法登录Django Admin面板。
当开发者尝试构建一个基于电子邮件的自定义用户模型，并继承自AbstractBaseUser和PermissionsMixin时，可能会遇到超级用户在Django Admin登录时反复提示“请输入正确的电子邮件和密码”的错误，即使确认凭据无误。这个问题通常发生在以下场景：
自定义用户模型 (Customers):
from django.utils import timezone
from django.db import models
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, UserManager
# 自定义管理器
class CustomerManager(UserManager):
def _create_user(self, email, password, **extra_fields):
if not email:
raise ValueError('Customers must have an email address')
user = self.model(
email=email,
**extra_fields
)
user.set_password(password) # 使用Django内置方法设置密码
user.save(using=self._db)
return user
def create_user(self, email=None, password=None, **extra_fields):
extra_fields.setdefault('is_superuser', False)
extra_fields.setdefault('is_staff', False)
return self._create_user(email, password, **extra_fields)
def create_superuser(self, name, last_name, email, phone, password, **kwargs):
kwargs.setdefault('is_superuser', True)
kwargs.setdefault('is_staff', True)
return self._create_user(email, password, **kwargs)
# 自定义用户模型
class Customers (AbstractBaseUser, PermissionsMixin):
name = models.CharField(max_length=20)
last_name = models.CharField(max_length=20)
email = models.EmailField(blank=False, unique=True)
phone = models.CharField(max_length=15)
password = models.CharField(max_length=20) # 错误：重复定义密码字段
is_active = models.BooleanField(default=True)
is_staff = models.BooleanField(default=False)
is_superuser = models.BooleanField(default=False) # 错误：重复定义is_superuser
date_joined = models.DateTimeField(default=timezone.now)
last_login = models.DateTimeField(blank=True, null=True)
objects = CustomerManager()
USERNAME_FIELD = 'email'
EMAIL_FIELD = 'email'
REQUIRED_FIELDS = ['name', 'last_name', 'phone']
class Meta:
verbose_name = 'Customer'
verbose_name_plural = 'Customers'
def get_full_name(self):
return self.name + ' ' + self.last_name
def get_short_name(self):
return self.name
def check_password(self, password): # 错误：覆盖了AbstractBaseUser的密码验证方法
return self.password == passwordsettings.py配置:
AUTH_USER_MODEL = 'customers.Customers'
尽管在自定义管理器中使用了user.set_password(password)来设置密码，但由于模型内部的错误定义，导致登录验证失败。
上述问题的核心在于对AbstractBaseUser和PermissionsMixin这两个基类提供的核心功能的重复定义和不当覆盖。
password 字段的重复定义:AbstractBaseUser基类已经包含了对用户密码的管理，它会在内部维护一个经过哈希处理的密码字段。当我们在Customers模型中再次定义password = models.CharField(max_length=20)时，实际上是创建了一个新的、未经Django哈希机制处理的明文字段。虽然CustomerManager中的set_password方法会调用AbstractBaseUser的set_password来正确哈希密码并存储，但当Django尝试验证密码时，它可能会错误地使用我们自定义的明文password字段，或者在后续的数据库操作中造成混淆。
is_superuser 字段的重复定义:PermissionsMixin基类已经提供了is_superuser和is_staff等权限相关的布尔字段。重复定义is_superuser = models.BooleanField(default=False)同样会导致不必要的冗余和潜在的冲突。
check_password 方法的覆盖:AbstractBaseUser提供了一个健壮且安全的check_password方法，用于验证用户输入的密码与数据库中存储的哈希密码是否匹配。通过自定义def check_password(self, password): return self.password == password，我们完全覆盖了Django内置的安全验证逻辑。这个自定义方法直接比较了用户输入的密码与模型中自定义的明文password字段，这不仅不安全（因为密码以明文形式存储或被错误处理），也绕过了Django的哈希密码验证机制，从而导致登录失败。
解决此问题的关键在于移除自定义用户模型中与AbstractBaseUser和PermissionsMixin功能重复的字段和方法，充分信任并利用Django提供的内置认证机制。
修正后的 Customers 模型:
from django.utils import timezone
from django.db import models
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, UserManager
# CustomerManager 保持不变，因为它正确地使用了 set_password
class CustomerManager(UserManager):
def _create_user(self, email, password, **extra_fields):
if not email:
raise ValueError('Customers must have an email address')
user = self.model(
email=email,
**extra_fields
)
user.set_password(password)
user.save(using=self._db)
return user
def create_user(self, email=None, password=None, **extra_fields):
extra_fields.setdefault('is_superuser', False)
extra_fields.setdefault('is_staff', False)
return self._create_user(email, password, **extra_fields)
def create_superuser(self, name, last_name, email, phone, password, **kwargs):
kwargs.setdefault('is_superuser', True)
kwargs.setdefault('is_staff', True)
return self._create_user(email, password, **kwargs)
# 修正后的自定义用户模型
class Customers (AbstractBaseUser, PermissionsMixin):
name = models.CharField(max_length=20)
last_name = models.CharField(max_length=20)
email = models.EmailField(blank=False, unique=True)
phone = models.CharField(max_length=15)
# 移除 password 字段，AbstractBaseUser 已提供
is_active = models.BooleanField(default=True)
is_staff = models.BooleanField(default=False)
# 移除 is_superuser 字段，PermissionsMixin 已提供
date_joined = models.DateTimeField(default=timezone.now)
last_login = models.DateTimeField(blank=True, null=True)
objects = CustomerManager()
USERNAME_FIELD = 'email'
EMAIL_FIELD = 'email'
REQUIRED_FIELDS = ['name', 'last_name', 'phone']
class Meta:
verbose_name = 'Customer'
verbose_name_plural = 'Customers'
def get_full_name(self):
return self.name + ' ' + self.last_name
def get_short_name(self):
return self.name
# 移除 check_password 方法，AbstractBaseUser 已提供安全的验证逻辑修改说明：
通过这些修改，自定义用户模型将正确地继承和利用Django内置的认证和权限管理功能，从而使超级用户能够顺利登录Admin面板。
在Django中构建自定义用户模型是一项常见的任务，但它要求开发者对AbstractBaseUser和PermissionsMixin的内部工作原理有清晰的理解。当遇到超级用户无法登录Admin面板的问题时，首先应检查自定义模型中是否存在对这些基类功能的重复定义或不当覆盖，特别是关于密码字段和验证方法。通过精简模型，移除冗余字段和方法，并充分利用Django内置的安全认证机制，可以确保自定义用户模型不仅功能完善，而且安全可靠地与Django Admin系统集成。
以上就是Django自定义用户模型：Admin登录失效与正确实现指南的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
989
收藏
