[Django]-Admin page on django is broken

Try this; in tests.py:

from django.contrib import auth

class AuthTestCase(TestCase):
    def setUp(self):
        self.u = User.objects.create_user('test@dom.com', 'test@dom.com', '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='test@dom.com', password='pass')

Then run the test with python manage.py test <your_app_name>.AuthTestCase. If this passes, the system is working, maybe look at the username and password to make sure they are acceptable.

I had the same issue, but AUTHENTICATION_BACKENDS flag on settings file was not the problem for me. Using Django Rest Framework somehow i had modified the password without calling set_password therefore bypassing hashing the password. That’s why it was showing the invalid login.

I was able to detect the issue by running simple test in order to test the user creation by a similar test:

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('test@dom.com', '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='test@dom.com', password='pass')

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

Are you using a custom user model and forgot add it in settings.py? That is what just happened to me.

# Substituting a custom User model

AUTH_USER_MODEL = "app_custom_auth.User"

You just need to delete the db.sqlite3 and migrate again (python manage.py migrate) then do:

python manage.py createsuperuser

to create the account again.

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”;

Then you can login again!

The answer is :

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

is_active and is_staff must be True to log in Django Admin so in these cases below, you can log in 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 any custom middleware in settings.py and see if that solves your problem.

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)