Un model de utilizator personalizat înlocuiește User-ul implicit al Django-ului pentru a se adapta nevoilor aplicației tale — adăugând câmpuri, schimbând identificatorul de conectare (de exemplu email în loc de nume de utilizator) sau personalizând comportamentul. Sfatul critic și des repetat: configurează un model de utilizator personalizat chiar de la început al unui proiect, chiar dacă nu ai nevoie de modificări acum, pentru că schimbarea lui mai târziu este extrem de dureroasă.
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.
Acesta este lecția practică cheie: costă aproape nimic să configurezi un model de utilizator personalizat în prima zi, dar adaptarea unuia unui proiect stabilit este o sarcină majoră, predispusă erorilor — deci o faci de la început ca o asigurare.
# 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 păstrează toate câmpurile implicite ale Django-ului și mecanismul de autentificare — pur și simplu adaugi câmpuri. Abordarea cea mai simplă și mai comună.
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 oferă control total asupra modelului de utilizator (de exemplu, eliminarea completă a numelui de utilizator pentru conectare doar cu email) — mai multă muncă, dar flexibilitate maximă.
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
Referențiază întotdeauna modelul de utilizator prin settings.AUTH_USER_MODEL (în modele) și get_user_model() (în cod), nu prin import direct al User-ului implicit — așa codul tău funcționează cu modelul personalizat.
Utilizarea unui model de utilizator personalizat este cunoaștere importantă cu o lecție practică critică, des accentuată, pe care fiecare dezvoltator Django ar trebui să o internalizeze: configurează-o de la foarte începutul fiecărui proiect.
Motivul pentru care aceasta contează atât de mult este asimetria severă în dificultate — definirea unui model de utilizator personalizat în prima zi (chiar o subclasă AbstractUser goală) costă aproape nimic și oferă flexibilitate inestimabilă, în timp ce comutarea la un model de utilizator personalizat după ce proiectul are migrații și date este extrem de dureroasă și riscantă, deoarece modelul User este profund referențiat în întregul Django (autentificare, admin, sesiuni) și prin chei externe în întreaga bază de date, necesitând migrații de date complexe și predispuse erorilor pentru a se schimba.
Acesta este motivul pentru care documentația proprie a Django recomandă puternic un model de utilizator personalizat pentru fiecare proiect nou, indiferent de nevoie imediată — este o asigurare împotriva unei nightmare de migrație viitoare.
Dincolo de acest sfat critic cu privire la sincronizare, înțelegerea cum să creezi modele de utilizator personalizate — AbstractUser pentru a adăuga pur și simplu câmpuri în timp ce păstrezi comportamentul de autentificare al Django-ului (cazul obișnuit, ușor), și AbstractBaseUser pentru control total, cum ar fi conectarea pe bază de email (eliminând complet numele de utilizator) — este valoroasă pentru îndeplinirea cerințelor aplicației reale (câmpuri de utilizator suplimentare, identificatori de conectare alternativi, autentificare personalizată).
La fel de important este să știi să referenciezi corect modelul de utilizator (prin settings.AUTH_USER_MODEL și get_user_model(), niciodată un import direct) așa că codul funcționează cu orice model de utilizator este configurat.
Deoarece aproape fiecare aplicație reală are necesități specifice utilizatorului dincolo de valorile implicite ale Django-ului (și chiar și cele care nu beneficiază de flexibilitate), și deoarece costul de a nu configura asta devreme este atât de mare, înțelegerea modelelor de utilizator personalizate — mai ales imperativul de a stabili una la începerea proiectului — este cunoaștere importantă, practic-critică, care previne o greșeală comună și serioasă la nivel de proiect, făcând-o o bucată frecvent citată de înțelepciune de bună practică Django.