Perché e come dovresti utilizzare un modello utente personalizzato?

Question

Accepted Answer

Un **modello utente personalizzato** sostituisce il default `User` di Django per adattarsi alle esigenze della tua applicazione — aggiungendo campi, modificando l'identificativo di accesso (ad es. email al posto del nome utente), o personalizzando il comportamento. Il consiglio critico e ripetuto frequentemente: configura un modello utente personalizzato **fin dall'inizio** di un progetto, anche se non hai bisogno di cambiamenti ora, perché modificarlo in seguito è estremamente difficile.

## Perché è importante

```text
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
```

## Il motivo critico per farlo PRIMA

```text
⚠️ 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.
```

Questa è la lezione pratica fondamentale: non costa quasi nulla configurare un modello utente personalizzato al primo giorno, ma adattarne uno a un progetto già consolidato è un'impresa importante e soggetta a errori — quindi lo fai fin dall'inizio come assicurazione.

## Come: estendere AbstractUser (il modo facile)

```python
# 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)
```

```python
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
```

`AbstractUser` mantiene tutti i campi predefiniti di Django e la sua macchina di autenticazione — devi solo aggiungere campi. L'approccio più semplice e comune.

## Come: AbstractBaseUser (controllo completo, ad es. accesso via email)

```python
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` offre controllo completo sul modello utente (ad es. rimuovere completamente il nome utente per un accesso solo via email) — più lavoro, ma massima flessibilità.

## Fare riferimento al modello utente correttamente

```python
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
```

Fai sempre riferimento al modello utente tramite `settings.AUTH_USER_MODEL` (nei modelli) e `get_user_model()` (nel codice), mai importando direttamente il default `User` — così il tuo codice funziona con il modello personalizzato.

## Perché è importante

Utilizzare un modello utente personalizzato è una conoscenza importante con una lezione pratica critica e enfatizzata frequentemente che ogni sviluppatore Django dovrebbe interiorizzare: **configuralo fin dall'inizio di ogni progetto**.

Il motivo per cui è così importante è l'asimmetria severa nella difficoltà — definire un modello utente personalizzato al primo giorno (anche una semplice sottoclasse di `AbstractUser`) non costa quasi nulla e fornisce flessibilità inestimabile, mentre passare a un modello utente personalizzato *dopo* che il progetto ha migrazioni e dati è estremamente difficile e rischioso, perché il modello User è profondamente referenziato in tutta Django (autenticazione, admin, sessioni) e da chiavi esterne in tutto il tuo database, richiedendo migrazioni dati complesse e soggette a errori per cambiare.

È per questo che la documentazione ufficiale di Django consiglia fortemente un modello utente personalizzato per ogni nuovo progetto, indipendentemente dalle necessità immediate — è assicurazione contro un incubo futuro di migrazione.

Al di là di questo consiglio di tempistica critico, comprendere *come* creare modelli utente personalizzati — **`AbstractUser`** per aggiungere semplicemente campi mantenendo il comportamento di autenticazione di Django (il caso comune e facile), e **`AbstractBaseUser`** per controllo completo come accesso basato su email (rimuovendo completamente il nome utente) — è prezioso per soddisfare requisiti reali dell'applicazione (campi utente extra, identificativi di accesso alternativi, autenticazione personalizzata).

Equalmente importante è sapere di **fare riferimento al modello utente correttamente** (tramite `settings.AUTH_USER_MODEL` e `get_user_model()`, mai un importazione diretta) così il codice funziona con qualsiasi modello utente sia configurato.

Poiché quasi ogni applicazione reale ha esigenze specifiche dell'utente oltre i valori predefiniti di Django (e anche quelli che non le hanno beneficiano della flessibilità), e perché il costo di non configurarlo presto è così alto, comprendere i modelli utente personalizzati — soprattutto l'imperativo di stabilirne uno all'inizio del progetto — è una conoscenza importante, praticamente critica, che previene un errore comune e serio a livello di progetto, rendendola una saggezza frequentemente citata di Django best-practice.