Bir özel kullanıcı modeli, Django'nun varsayılan User modelinin yerine geçerek uygulamanızın ihtiyaçlarına uyum sağlar — alanlar ekleyebilir, oturum açma tanımlayıcısını değiştirebilir (örneğin kullanıcı adı yerine e-posta) veya davranışı özelleştirebilirsiniz. Kritik ve sık tekrarlanan tavsiye: henüz değişikliklere ihtiyacınız olmasa bile, bir projenin en başında özel bir kullanıcı modeli kurun, çünkü bunu daha sonra değiştirmek son derece zorlayıcıdır.
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.
Bu ana pratik ders: birinci gün özel bir kullanıcı modeli kurmak neredeyse hiçbir maliyeti olmaz, ancak bir yerleşik projeye geriye dönük uygulamak büyük ve hata eğilimli bir görevdir — bu nedenle bunu sigorta olarak önceden yaparsınız.
# 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 Django'nun tüm varsayılan alanlarını ve kimlik doğrulama mekanizmasını tutar — siz sadece alanlar eklersiniz. En basit ve en yaygın yaklaşım.
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 kullanıcı modeli üzerinde tam kontrol sağlar (örneğin e-posta ile sadece giriş için kullanıcı adını tamamen kaldırma) — daha fazla iş, ancak maksimum esneklik.
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
Kullanıcı modelini her zaman settings.AUTH_USER_MODEL (modellerinde) ve get_user_model() (kodda) aracılığıyla referans gösterin, varsayılan User'ı doğrudan içe aktarmayın — böylece kodunuz özel model ile çalışır.
Özel bir kullanıcı modeli kullanmak, her Django geliştiricisinin içselleştirmesi gereken kritik ve sık vurgulanan pratik bir dersle birlikte önemli bir bilgidir: her projenin en başında bunu kurun.
Bunun bu kadar önemli olmasının nedeni zorluk açısından ciddi asimetridir — birinci gün özel bir kullanıcı modeli tanımlamak (boş bir AbstractUser alt sınıfı bile) neredeyse hiçbir maliyeti olmaz ve değerli esneklik sağlar, oysa projenin migrationlar ve veri içermesinin ardından özel bir kullanıcı modeline geçmek son derece zorlayıcı ve risklidir, çünkü User modeli Django'nun tamamında (kimlik doğrulama, admin, oturumlar) ve tüm veritabanınız genelinde yabancı anahtarlar tarafından derin şekilde referans gösterilen bir modeldir ve değiştirmek karmaşık, hata eğilimli veri migrasyonları gerektirir.
Django'nun kendi dokümantasyonu bu nedenle, acil bir ihtiyaç olup olmadığına bakılmaksızın, her yeni proje için özel bir kullanıcı modeli önermenin nedeni budur — gelecekteki bir migration kabusunun önüne geçmek için bir sigortadır.
Bu kritik zamanlama tavsiyesinin ötesinde, özel kullanıcı modellerinin nasıl oluşturulacağını anlamak — Django'nun auth davranışını tutarken alan eklemeyi sağlayan AbstractUser (yaygın, kolay durum), ve e-posta ile giriş gibi tam kontrol için AbstractBaseUser (kullanıcı adını tamamen kaldırma) — gerçek uygulama gereksinimlerini karşılamak için değerlidir (ek kullanıcı alanları, alternatif giriş tanımlayıcıları, özel kimlik doğrulama).
Eşit derecede önemli olan şey, kullanıcı modelini doğru şekilde referans göstermek bilmektir (settings.AUTH_USER_MODEL ve get_user_model() aracılığıyla, asla doğrudan bir içe aktarma değil) böylece kod yapılandırılan hangi kullanıcı modeli olursa olsun çalışır.
Hemen hemen her gerçek uygulamanın Django'nun varsayılanlarının ötesinde kullanıcıya özgü ihtiyaçları vardır (ve bunların olmayan uygulamalar bile esneklikten yararlanır), ve bunu erkenden kurmamanın maliyeti bu kadar yüksek olduğu için, özel kullanıcı modellerini anlamak — özellikle proje başında bunu kurmak zorunluluğu — yaygın ve ciddi bir proje düzeyindeki hatayı önleyen önemli, pratik açıdan kritik bilgidir ve sık alıntı yapılan Django en iyi uygulama bilgeliğidir.