Een aangepast gebruikersmodel vervangt Django's standaard User om aan de behoeften van je toepassing te voldoen — velden toevoegen, de login-identifier wijzigen (bijv. e-mail in plaats van gebruikersnaam) of gedrag aanpassen. Het kritieke, vaak herhaalde advies: stel een aangepast gebruikersmodel helemaal aan het begin van een project op, zelfs als je nu geen wijzigingen nodig hebt, omdat het later veranderen uiterst pijnlijk is.
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
✓ Email-based login (no username)
✓ Extra fields (phone, avatar, role, preferences) on the user itself
✓ Custom authentication behavior
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
referenced by auth, admin, sessions, foreign keys throughout the database.
Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
even an empty one, so you can extend it freely later. Django's docs strongly
recommend this for EVERY new project.
Dit is de belangrijkste praktische les: het kost bijna niets om op dag één een aangepast gebruikersmodel op te zetten, maar het invoegen ervan in een bestaand project is een grote, foutgevoelige onderneming — dus je doet het van tevoren als verzekering.
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
AbstractUser behoudt alle standaardvelden en authenticatiemechanismen van Django — je voegt gewoon velden toe. De eenvoudigste, meest voorkomende aanpak.
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # log in with EMAIL instead of username
REQUIRED_FIELDS = []
objects = CustomUserManager() # a manager defining create_user/create_superuser
AbstractBaseUser geeft volledige controle over het gebruikersmodel (bijv. gebruikersnaam helemaal verwijderen voor alleen e-maillogin) — meer werk, maar maximale flexibiliteit.
from django.conf import settings
from django.contrib.auth import get_user_model
# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# in code — get the active user model dynamically
User = get_user_model() # NOT a direct import of the default User
Refereer altijd naar het gebruikersmodel via settings.AUTH_USER_MODEL (in modellen) en get_user_model() (in code), nooit door rechtstreeks de standaard User te importeren — zodat je code werkt met het aangepaste model.
Een aangepast gebruikersmodel gebruiken is belangrijke kennis met een kritieke, regelmatig benadrukte praktische les die elke Django-ontwikkelaar zou moeten internaliseren: stel het aan het begin van elk project op.
De reden dat dit zo belangrijk is, is de ernstige asymmetrie in moeilijkheid — het definiëren van een aangepast gebruikersmodel op dag één (zelfs een lege AbstractUser-subklasse) kost bijna niets en biedt onschatbare flexibiliteit, terwijl overschakelen naar een aangepast gebruikersmodel nadat het project migraties en gegevens heeft, uiterst pijnlijk en riskant is, omdat het User-model diep verankerd is in Django (authenticatie, admin, sessies) en door buitenlandse sleutels in je hele database, vereisend complexe, foutgevoelige gegevensmigraties om te wijzigen.
Daarom beveelt Django's eigen documentatie sterk een aangepast gebruikersmodel voor elk nieuw project aan, ongeacht onmiddellijke behoefte — het is verzekering tegen een toekomstige migratie-nachtmerrie.
Naast dit kritieke timing-advies is het begrijpen van hoe je aangepaste gebruikersmodellen maakt — AbstractUser voor het eenvoudig toevoegen van velden terwijl je Django's auth-gedrag behoudt (het veel voorkomende, gemakkelijke geval), en AbstractBaseUser voor volledige controle zoals e-mailgebaseerde login (gebruikersnaam helemaal verwijderen) — waardevol voor het voldoen aan echte toepassingsvereisten (extra gebruikersvelden, alternatieve login-identificeermiddelen, aangepaste authenticatie).
Evenso belangrijk is te weten dat je het gebruikersmodel correct moet refereren (via settings.AUTH_USER_MODEL en get_user_model(), nooit een directe import) zodat code werkt met welk gebruikersmodel dan ook is geconfigureerd.
Omdat bijna elke echte toepassing gebruikersspecifieke behoeften heeft die verder gaan dan Django's standaardinstellingen (en zelfs degenen die niet profiteren van de flexibiliteit), en omdat de kosten van het niet van tevoren opzetten zo hoog zijn, is het begrijpen van aangepaste gebruikersmodellen — vooral het imperatief om er één aan het begin van het project in te stellen — belangrijke, praktisch-kritieke kennis die een veel voorkomende en serieuze fout op projectniveau voorkomt, waardoor het een veel geciteerd stuk Django best-practice-wijsheid wordt.