En anpassad användarmodell ersätter Djangos standardmodell User för att passa din applikations behov — genom att lägga till fält, ändra inloggningsidentifierare (t.ex. e-post istället för användarnamn) eller anpassa beteende. Det kritiska, ofta upprepade rådet: konfigurera en anpassad användarmodell redan från början av ett projekt, även om du inte behöver ändringar än, för att ändra det senare är extremt smärtsamt.
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.
Detta är den viktigaste praktiska läxan: det kostar nästan ingenting att konfigurera en anpassad användarmodell på dag ett, men att montera en efteråt på ett etablerat projekt är en stor, felbenägen operation — så du gör det på förhand som försäkring.
# 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 behåller alla Djangos standardfält och autentiseringsmaskiner — du lägger bara till fält. Det enklaste, mest vanliga tillvagagångssättet.
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 ger full kontroll över användarmodellen (t.ex. att ta bort användarnamn helt för endast e-postinloggning) — mer arbete, men maximal flexibilitet.
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
Referera alltid till användarmodellen via settings.AUTH_USER_MODEL (i modeller) och get_user_model() (i kod), aldrig genom att importera standardanvändaren direkt — så att din kod fungerar med den anpassade modellen.
Att använda en anpassad användarmodell är viktig kunskap med en kritisk, ofta betonad praktisk läxa som varje Django-utvecklare bör ta till sig: konfigurera den redan från början av varje projekt.
Anledningen till att detta spelar så stor roll är den allvarliga asymmetrin i svårighet — att definiera en anpassad användarmodell på dag ett (även en tom AbstractUser-underklass) kostar nästan ingenting och ger ovärderlig flexibilitet, medan övergång till en anpassad användarmodell efter att projektet har migreringar och data är extremt smärtsamt och riskabelt, för användarmodellen refereras djupt i hela Django (autentisering, admin, sessioner) och av främmande nycklar över hela din databas, vilket kräver komplexa, felbenägna datamigreringar för att ändra.
Detta är varför Djangos egen dokumentation starkt rekommenderar en anpassad användarmodell för varje nytt projekt, oavsett omedelbar behov — det är försäkring mot ett framtida migreringsmardrömscenario.
Utöver detta kritiska tidningsråd är förståelse för hur man skapar anpassade användarmodeller — AbstractUser för att helt enkelt lägga till fält samtidigt som man behåller Djangos autentiseringsbeteende (det vanliga, enkla fallet), och AbstractBaseUser för full kontroll som e-postbaserad inloggning (ta bort användarnamn helt) — värdefullt för att möta verkliga applikationskrav (extra användarfält, alternativa inloggningsidentifierare, anpassad autentisering).
Lika viktigt är att veta att referera till användarmodellen korrekt (via settings.AUTH_USER_MODEL och get_user_model(), aldrig en direkt import) så att kod fungerar med vilken användarmodell som helst som är konfigurerad.
Eftersom nästan varje verklig applikation har användarspecifika behov utöver Djangos standardinställningar (och även de som inte gör det drar nytta av flexibiliteten), och eftersom kostnaden för att inte konfigurera detta tidigt är så högt, är förståelse för anpassade användarmodeller — särskilt kravet på att etablera en vid projektstart — viktig, praktiskt-kritisk kunskap som förhindrar ett vanligt och allvarligt projektomfattande misstag, vilket gör det till ett ofta citerat stycke Django best-practice-visdom.