Django Multi-tenancy with custom authentication

Hello, before telling the problem let me explain my project architecture a little bit. I try to build an app that supports multitenancy in django. The app uses postgresql database. I do not want to use different schema for each tenant. So I will store all tenants data into same schema and same table but with different . Well, I designed the all database architecture of project and created all models. Now lets talk about my project’s accounts model. In that model I’ve defined all attributes of user table. Of course I added attribute as well.
And I’ve build a custom authentication model to allow users login with email. When I migrate the changes it’s okay. But once I try to createsuperuser in the terminal it gives an error such as
value too long for type character varying(50) . I’ve researched and tried some answers but did not solve the problem.
And another thing that I want to understand is if I try to create a superuser does django want me a tenant id too just because of my multitenant user model ? Thanks in advance

My first question would be, how have you altered the standard User model?

The built-in createsuperuser command is fairly rigid with what it expects in terms of the user model, and if you’ve made significant changes to it, it’s no longer going to work. (As you’ve seen…)

Thanks for your care, in my accounts app’s file I’ve created 2 class. First one is Account class that is inherited from AbstractBaseUser and I’ve defined all the attributes with attribute inside this class. And the second class is MyAccountManager and this is inherited from BaseUserManager. I’ve used second class to set creating user options.
in the accounts file I created a class called AccountAdmin and this class was inherited from UserAdmin which is from django.contrib.auth.admin
Finally I created a file called into accounts app. There is a class called MyModelBackend that has been inherited from ModelBackend class.
I’ve done this before in a project but without multitenancy support. It worked like a charm
But now in this multitenant supported project there is a weird reason that I could not find yet.
As for your question I’ve changed the standart user model and created a custom one. And I’ve changed the authentication options too to make my custom user model work. But as I said creating superuser gives error.
Btw I do not use any 3rd part library such as django-multitenant etc.

That’s the key part.

The createsuperuser command is tied to the standard user object. You can examine the file to see how changes you have made may affect it.

I got it but when I type :
python createsuperuser it shows me email and password fill to sign up. It doesn’t want username field anymore. Doesn’t that mean my custom model work as its purpose.
I really appreciate for your help

At this point, I think I’d need to see your custom user model and the complete traceback from the error message you’re receiving.

Well there it is. file

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager

# Create your models here.
def validateEmail(e_mail):
    from django.core.validators import validate_email
    from django.core.exceptions import ValidationError
        return True
    except ValidationError:
        return False

class MyAccountManager(BaseUserManager):  # These class will be use for creating user options
    def create_user(self, e_mail, username, password=None):
        if (not e_mail) or (not validateEmail(e_mail)):
            raise ValueError("Kullanicinin bir email adresi olmali")
        if not username:
            raise ValueError("Kullanicinin bir kullanici adi olmali")
        user = self.model(
        return user

    def create_superuser(self, e_mail, username, password):
        user = self.create_user(e_mail=self.normalize_email(e_mail),
                                password=password, )
        user.is_admin = True
        user.is_staff = True
        user.is_superuser = True
        return user

def get_profile_image_filepath(self):
    return f'profile_images/{}/{"profile_img.png"}'
def get_default_profile_image():
    return "images/default_profile_image.png"

class Account(AbstractBaseUser):
    customer = models.ForeignKey('customers.Customer', null=False, blank=False, verbose_name='Customer',
                                 on_delete=models.CASCADE, related_name='customeraccount')
    name = models.CharField(max_length=50, verbose_name='Name')
    surname = models.CharField(max_length=50, verbose_name='Surname')
    address = models.CharField(max_length=300,blank=True, verbose_name='Address')
    birth_date = models.DateTimeField(verbose_name='UserBirthDate', auto_now_add=False)
    diseases = models.CharField(max_length=500,blank=True, verbose_name='Diseases')
    duty = models.CharField(max_length=300,blank=True,default='yok', verbose_name='Duty')

    username = models.CharField(max_length=50, verbose_name='Username',unique=True, null=False, blank=False)
    password = models.CharField(max_length=50, verbose_name='Password', null=False, blank=False)
    e_mail = models.CharField(max_length=60,blank=True,unique=True, verbose_name='Email')
    registered_date = models.DateTimeField(verbose_name='Registered Date', auto_now_add=True)
    profile_image = models.ImageField(max_length=255,upload_to=get_profile_image_filepath, null=True, blank=True, default=get_default_profile_image)

    is_admin = models.BooleanField(default=False) #These four properties are require because we use abstractbaseuser we must overwrite these properties
    is_active = models.BooleanField(default=True)
    is_staff = models.BooleanField(default=False)
    is_superuser = models.BooleanField(default=False)

    hide_email = models.BooleanField(default=True)
    is_manager = models.BooleanField(default=False)
    is_assistant = models.BooleanField(default=False)
    is_deleted = models.BooleanField(default=False)

    objects = MyAccountManager()  # user registiration options defining here
    USERNAME_FIELD = 'username'
    REQUIRED_FIELDS = ['e_mail']

    def __str__(self):
        return + ' ' + self.surname
    ################################## the below two functions must be overwritten to be able to use custom user login
    def has_perm(self,perm,obj=None):
        return self.is_admin
    def has_module_perms(self, app_label):
        return True file :

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from accounts.models import Account
# Register your models here.

class AccountAdmin(UserAdmin):
    readonly_fields = ('id','registered_date')
    filter_horizontal = ()
    list_filter = ()
    fieldsets = ()
        (None, {
    ),AccountAdmin) file:

from django.contrib.auth import get_user_model
from django.contrib.auth.backends import ModelBackend

# this class has been created for ignoring the case sensitivity on email during login
class CaseInsensitiveModelBackend(ModelBackend):
    def authenticate(self,request,username=None,password=None,**kwargs):
        UserModel = get_user_model()
        if username is None:
            username = kwargs.get(UserModel.USERNAME_FIELD)
                case_insensitive_username_field = '{}__iexact'.format(UserModel.USERNAME_FIELD)
                user = UserModel._default_manager.get(**{case_insensitive_username_field:username})
            except UserModel.DoesNotExist:
                if (user.check_password(password) and self.user_can_authenticate(user)):
                    return user

in the file I also added :

AUTH_USER_MODEL = "accounts.Account"

Additionally this is customer :
from django.db import models

# Create your models here.
class Customer(models.Model):
    name = models.CharField(max_length=60, verbose_name='Name', unique=True)
    registration_date = models.DateTimeField(verbose_name='Registration Date', auto_now_add=True)
    city = models.ForeignKey('cities.Cities', null=False,blank=False,default=1, verbose_name='City', on_delete=models.CASCADE,related_name='customercity')
    def __str__(self):

And this is the full traceback :

Traceback (most recent call last):
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 84, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.StringDataRightTruncation: value too long for type character varying(50)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 22, in <module>
  File "", line 18, in main
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/core/management/", line 419, in execute_from_command_line
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/core/management/", line 413, in execute
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/core/management/", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/contrib/auth/management/commands/", line 79, in execute
    return super().execute(*args, **options)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/core/management/", line 398, in execute
    output = self.handle(*args, **options)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/contrib/auth/management/commands/", line 189, in handle
  File "/home/vedat/Desktop/CRECHEPROJECT/accounts/", line 28, in create_superuser
    user = self.create_user(e_mail=self.normalize_email(e_mail),
  File "/home/vedat/Desktop/CRECHEPROJECT/accounts/", line 24, in create_user
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/contrib/auth/", line 67, in save
    super().save(*args, **kwargs)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 726, in save
    self.save_base(using=using, force_insert=force_insert,
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 763, in save_base
    updated = self._save_table(
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 868, in _save_table
    results = self._do_insert(cls._base_manager, using, fields, returning_fields, raw)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 906, in _do_insert
    return manager._insert(
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/", line 1270, in _insert
    return query.get_compiler(using=using).execute_sql(returning_fields)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/models/sql/", line 1416, in execute_sql
    cursor.execute(sql, params)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 98, in execute
    return super().execute(sql, params)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 66, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 75, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/home/vedat/Desktop/CRECHEPROJECT/venv/lib/python3.8/site-packages/django/db/backends/", line 84, in _execute
    return self.cursor.execute(sql, params)
django.db.utils.DataError: value too long for type character varying(50)

I have no idea whether or not this is a “problem”, but the calling sequence for create_superuser identifies the first positional parameter as being the username - which you’ve defined as username. But your implementation of create_superuser has e_mail first and username second.

If I were trying to diagnose this, I’d be looking at what parameters are being passed around at different points to verify what values are being supplied. (Either using the debugger or by adding print calls at key locations.)

Got it sir. I’ve a question that I really want to know.
When I type python createsuperuser it shows me username email password1 and password2 fields. if I fill this fields will django save these fields into my Account table that I have just created or into another table that specific for admin accounts that django uses. I’m asking this because in the Account table there is customer field needed to be fill as well. When I create superuser there will be no value to fill customer field right ? it cause an logical error.

It saves username, email, and the hashed password into your Account table.

Correct. Unless customer is listed in REQUIRED_FIELDS, you won’t be prompted for it - which would throw an error unless your save method created an instance of Customer and assigned that pk to the customer field. (However, I don’t believe listing customer in REQUIRED_FIELDS is much of an improvement, since my guess would be that the Customer instance would already need to exist and you’d need to know its pk for assignment.)

Side note - I generally recommend that no foreign table relationships ever be placed in the User model. Our principle here is that a User is a fundamental entity, and any other tables needing to be related to a User define the relationship. We do have exceptions to that, but they are very well-defined. The idea is that you generally need to have one or more users who are “outside” the normal user structure and should not need to have “fake relationships” created just to satisfy a database constraint. In this case, you may have one or more superusers who really aren’t customers and shouldn’t have Customer data created for them. You prevent needing to do this by defining the OneToOne relationship in Customer rather than in Account.

I think I spotted it - the create_superuser is going to pass the password as the second parameter, which you have assigned to username. So it’s trying to assign the hashed password (longer than 50 characters) to a 50 character field. That is what is throwing the actual error.

(And that’s another issue as well - you have password assigned as a 50 character field, which isn’t sufficient. If you look at AbstractBaseUser, it defines password as a 128-character field. Since you’re inheriting from AbstractBaseUser, you don’t need to define a password field at all.)

I understood very well. I will keep your advice in mind so thank you so much