has_perm() raises exception when used with custom user inheriting AbstractUser

[Ivan Virabyan]

from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    avatar = models.ImageField(upload_to='avatars')


>>> user = CustomUser.objects.create_user(username='test', email='test@example.com')
>>> user.has_perm('test')
Traceback (most recent call last):
  ...
  File "django/django/db/models/fields/related.py", line 1197, in _get_m2m_reverse_attr
    for f in self.rel.through._meta.fields:
AttributeError: 'NoneType' object has no attribute '_meta'

This isn't reproducable in test environment, because m2m "through" table created before settings.CUSTOM_USER_MODEL is overriden.

[Ivan Virabyan]

don't expect custom user model to be called User

[Preston Holmes]

My hunch is that this is basically a duplicate of the issues in #19049

Can you check to see whether the fix there also resolves this?

[Ivan Virabyan]

No, it doesnt solve this problem. This bug is caused by auth backend, which assumes user model to have name User:
Permission.objects.filter(group__user=user_obj)

so when our custom model has name CustomUser, it doesnt work, because filter expression must be of the form group__customuser

[Russell Keith-Magee]

Agreed - this is definitely a problem, and your fix seems like a reasonable approach.

We really do need a way to test for the sort of problem that this report reveals (i.e., for Django's test suite to contain a test project that has AUTH_USER_MODEL defined at project startup). There have been several recent reports that have needed a clear way to test the "there isn't a default User model" case.

A related problem - I suspect we may be able to factor the has_perm calls onto AbstractBaseUser. They're completely generic anyway, relying on the auth backend for calculations; it seems weird to ask people to reproduce that logic. This may require further changes to the default auth backend to check whether permissions are in use at all.

[Russell Keith-Magee <russell@…>]

In b9039268a17b06e7fe069721e99f6d69181c344d:

Fixed #19060 -- Corrected assumptions about the name of the User model in the ModelBackend.

Thanks to Ivan Virabyan for the report and initial patch.