This problem may be related to the Authentication Backends. Please check your settings files for the AUTHENTICATION_BACKENDS parameter.

价值如下:

AUTHENTICATION_BACKENDS = (
    ( django.contrib.auth.backends.ModelBackend ),
)

More information on the Official Django Documentation

引证;测试。 py:

from django.contrib import auth

class AuthTestCase(TestCase):
    def setUp(self):
        self.u = User.objects.create_user( [email protected] ,  [email protected] ,  pass )
        self.u.is_staff = True
        self.u.is_superuser = True
        self.u.is_active = True
        self.u.save()

    def testLogin(self):
        self.client.login(username= [email protected] , password= pass )

然后用<代码>python管理进行测试。 py test <your_app_name>.Auth TestCase。 如果发放通行证,该系统就会发现用户名称和密码,以确保这些通行证可以接受。

我也有同样的问题,但是,在环境档案中悬挂BACKENDS旗帜并不是我的问题。 采用《Django 休息框架》,有点修改了密码,而没有打上密码,因此绕过了密码。 因此,它显示了无效的标志。

我得以通过简单的测试发现这一问题,以便通过类似的测试测试用户的生成:

from django.test import TestCase

from django.contrib import auth
from .models import *

class AuthTestCase(TestCase):
    def setUp(self):
        self.u = UserProfile.objects.create_user( [email protected] ,  iamtest ,  pass )
        self.u.is_staff = True
        self.u.is_superuser = True
        self.u.is_active = True
        self.u.save()

    def testLogin(self):
        self.client.login(username= [email protected] , password= pass )

It is also worth mentioning that I was creating a custom user named UserProfile

您是否使用习惯用户模型,是否在<编码>上添加这一模型? 这是我刚才的情况。

# Substituting a custom User model

AUTH_USER_MODEL = "app_custom_auth.User"

仅需要删除<代码>db.sqlite3,并再次迁移(python management)。 pymigration 然后:

python manage.py createsuperuser

重新设立账户。

You can do the following:

• Enter your mysql (or other database console)
• USE YourDATABASE;
• SELECT * from auth_user;
• watch is_staff and is_superuser item
• UPDATE auth_user SET is_staff = "1" where username = "root";

然后,你可以再次 log!

答案是:

def create_superuser(self, username, email, password=None, **extra_fields):
    user = self.create_user(username, email, password=password, is_staff=True, **extra_fields)
    user.is_active = True
    user.save(using=self._db)
    return

<>代码>_active和is_staff 须在Django Admin上登录True,在以下情况下,您可在Django Admin上登录:

is_active   ✅
is_staff    ✅
is_superusr

is_active   ✅
is_staff    ✅
is_superusr ✅

In addition, even if is_superusr is True, you cannot log in Django Admin in these cases below because making is_superusr True gives the user all permissions except logging in Django Admin:

is_active
is_staff    ✅
is_superusr ✅

is_active   ✅
is_staff
is_superusr ✅

is_active
is_staff
is_superusr ✅

Another issue that can cause this is custom middleware, as it can interfere with the request/response cycle. This interference might not always throw explicit errors but can prevent processes like authentication from completing successfully.

Try disabling anytom mediumware in dings.py, 并且看这是否解决了你的问题。

For example, converting the default Django WSGIRequest to a DRF Request object has side effects that can cause standard Django views (including Django Admin) to have issues. For example, the below custom_logging_middleware.py would cause issues logging into Django Admin:

from rest_framework.request import Request
import logging


class RequestLoggingMiddleware:

    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        start_time = time.time()
        logger = logging.getLogger(__name__)

        # Wrap the original request with DRF s Request, since the standard Django WSGIRequest doesn t have a .data attribute
        drf_request = Request(request)