Autentikasi yang telah disediakan Django sudah cukup baik untuk kasus-kasus pada umumnya, tetapi Anda mungkin memiliki kebutuhan yang tidak dipenuhi oleh fitur bawaan. Mengkostumisasi otentikasi pada proyek-proyek anda membutuhkan pengertian atas bagian-bagian tersedia yang dapat diturunkan atau diubah. Dokumen ini menyediakan detil tentang bagaimana sitem otentikasi dapat dikostumisasi.
\nAuthentication backends menyediakan sebuah sistem yang dapat diperpanjang untuk ketika nama pengguna dan sandi disimpan dengan model pengguna butuh untuk diotentifikasi terhadap layanan berbeda dari awalan Django.
\nAnda dapat memberikan model anda perizinan custom permissions yang dapat diperiksa melalui sistem otorisasi Django.
\nAnda dapat extend awalan model User, atau substitute sepenuhnya model disesuaikan.
Mungkin ada kali anda harus butuh mengait ke dalam sumber pembuktian keaslian lain -- yaitu, sumber lain dari nama pengguna dan sandi atau metode pembuktian keaslian.
\nSebagai contoh, perusahaan anda mungkin sudah mempunyai pengaturan LDAP yang menyimpan nama pengguna dan sandi untuk setiap karyawan. Itu akan menjadi cekcok untuk kedua administrator jaringan dan pengguna nya sendiri jika pengguna mempunyai akun terpisah di LDAP dan aplikasi berbasis-Django.
\nJadi, untuk menangani keadaan seperti ini, sistem pembuktian keaslian Django membiarkan anda memasang sumber pembuktian keaslian lain. Anda dapat menimpa skema berbasis-basisdata awal Django, atau anda dapat menggunakan sistem awal untuk dipasangkan dengan sistem lain.
\nLihat authentication backend reference untuk informasi pada backend otentifikasi yang disertakan dengan Django.
\nDibelakang layar, Django merawat daftar "backend pembuktian keaslian" yang dia periksa untuk pembuktian keaslian. Ketika seseorang memanggil django.contrib.auth.authenticate() -- seperti digambarkan di How to log a user in -- Django mencoba membuktikan keaslian disemua bakcend pembuktian keaslian itu. Jika metode pembuktian keaslian pertama gagal, Django mencoba yang kedua, dan selanjutnya, sampai semua backend telah dicoba.
Daftar backend pembuktian keaslian untuk digunakan ditentukan dalam pengaturan AUTHENTICATION_BACKENDS. Ini seharusnya daftar nama jalur Python yang menunjuk ke kelas Python yang mengetahui bagaimana membuktikan keaslian. Kelas ini dapat berada dimanapun di jalur Python anda.
Secara awal, AUTHENTICATION_BACKENDS disetel ke:
["django.contrib.auth.backends.ModelBackend"]\nItulah backend autentikasi dasar yang memeriksa basis data pengguna Django dan meminta izin bawaan. Itu tidak memberikan perlindungan terhadap serangan brute force melalui mekanisme pembatasan laju apa pun. Anda dapat menerapkan mekanisme pembatasan kecepatan anda sendiri di backend autentikasi khusus, atau menggunakan mekanisme yang disediakan oleh sebagian besar server web.
\nUrutan masalah AUTHENTICATION_BACKENDS, jadi jika nama pengguna dan sandi sama adalah sah di banyak backend, Django akan menghentikan pengolahan pada pertama yang positif cocok.
Jika backend memunculkan pengecualian PermissionDenied, pembuktian keaslian akan segera gagal. Django tidak akan memeriksa backend yang mengikuti.
Sebuah backend autentifikasi adalah sebuah kelas yang menerapkan dua metode wajib: get_user(user_id) dan authenticate(request, **credentials), dan juga kumpulan dari pilihan perizinan terhubung authorization methods.
Metode get_user mengambil user_id -- yang bisa berupa nama pengguna, ID basis data, atau apa pun, tetapi harus menjadi kunci utama objek pengguna Anda -- dan mengembalikan objek pengguna atau ``None` `.
Metode authenticate mengambil sebuah argumen request dan surat pengenal sebagai argumen kata kunci. Sebagian besar waktu, akan terlihat seperti ini
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nTetapi itu dapat juga membuktikan keaslian sebuah token, seperti begitu:
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nSalah satu cara, authenticate() harus memeriksa mandat yang dia dapatkan, dan dia harus mengembalikan obyek user yang cocok dengan mandat, jika mandat sah. Jika mereka tidak sah, dia harus mengembalikan None.
request adalah sebuah HttpRequest dan mungkin berupa None jika itu tidak disediakan pada authenticate() (yang melewatkan itu ke backend).
The Django admin is tightly coupled to the Django User object. For example, for a user to access the admin,\nUser.is_staff and User.is_active must be True (see\nAdminSite.has_permission() for details).
The best way to deal with this is to create a Django User object for each\nuser that exists for your backend (e.g., in your LDAP directory, your external\nSQL database, etc.). You can either write a script to do this in advance, or\nyour authenticate method can do it the first time a user logs in.
Here's an example backend that authenticates against a username and password\nvariable defined in your settings.py file and creates a Django User\nobject the first time a user authenticates. In this example, the created Django\nUser object is a superuser who will have full access to the admin:
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = settings.ADMIN_LOGIN == username\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username) # is_active defaults to True.\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\nUntuk membuat perizinan penyesuaian untuk obyek model yang diberikan, gunakan permissions model Meta attribute.
Contoh ini model Task membuat dua penyesuaian perizinan, yaitu, tindakan pengguna dapat atau tidak dapat dengan contoh-contoh Task, khusus ke aplikasi anda:
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n ]\nSatu-satunya hal yang dilakukan adalah membuat izin tambahan tersebut saat anda menjalankan manage.py migrate (fungsi yang membuat izin terhubung ke sinyal post_migrate). Kode anda bertugas memeriksa nilai izin ini saat pengguna mencoba mengakses kegunaan yang disediakan oleh aplikasi (mengubah status tugas atau menutup tugas.) Melanjutkan contoh di atas, berikut ini memeriksa apakah pengguna dapat menutup tugas:
user.has_perm("app.close_task")\nUser yang adaLink to this heading#Terdapat dua jalan untuk memperpanjang model User awal tanpa mengganti model milik anda. Jika perubahan anda butuhkan murni kebiasaan, dan tidak membutuhkan perubahan apapun ke apa ang disimpan di basisdata, anda dapat membuat proxy model berdasarkan pada User. Ini mengizinkan fitur apapun ditawarkan oleh model proxy termasuk pemesanan awal, pengelola penyesuaian, atau cara model penyesuaian.
Jika anda berharap menyimpan informasi terkait ke User, anda dapat menggunakan OneToOneField pada sebuah model mengandung bidang untuk informasi tambahan. Ini model satu-ke-satu selalu memanggil model profil, karena dia akan menyimpan informasi terkait bukan-asli tentang pengguna situs. Sebagai contoh anda mungkin membuat sebuah model Employee:
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nAsumsikan ada Karyawan Fred Smith yang memiliki model User dan Employee, anda dapat mengakses informasi terkait menggunakan konvensi model terkait standar Django:
\n>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\nUntuk menambahkan profil bidang model ke halaman pengguna dalam admin, tentukan sebuah class:~django.contrib.admin.InlineModelAdmin (untuk contoh ini, kami akan menggunakan StackedInline) di admin.py aplikasi anda dan menambahkannya ke kelas UserAdmin yang terdaftar dengan kelas User:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = "employee"\n\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nModel profil ini tidak khusus dengan cara apapun - mereka hanya model Django yang terjadi untuk memiliki tautan one-to-one dengan model user. Dengan demikian, mereka tidak dibuat otomatis ketika pengguna dibuat, tetapi django.db.models.signals.post_save dapat digunakan untuk membuat atau memperbaharui model sewajarnya.
menggunakan hasil model terkait di tambahan permintaan atau penggabungan untuk mendapatkan data terkait. Tergantung pada kebutuhan anda, penyesuaian model user yang menyertakan bidang terkait mungkin pilihan terbaik anda, bagaimanapun hubungan yang ada pada model user awalan dalam aplikasi proyek anda mungkin membenarkan muatan basisdata lebih.
\nUser penyesuaianLink to this heading#Beberapa macam proyek mungkin mempunyai persyaratan pembuktian keaslian untuk dimana model User siap-pakai Django tidak selalu sesuai. Sebagai contoh, pada beberapa situs akan masuk akal menggunakan sebuah alamat surel sebagai token pencirian daripada nama pengguna.
Django mengizinkan anda untuk menimpa model pengguna awalan dengan menyediakan nilai untuk pengaturan AUTH_USER_MODEL yang mengacu model penyesuaian:
AUTH_USER_MODEL = "myapp.MyUser"\nPasangan bertitik ini menjelaskan label dari aplikasi Django (yang harus ada di INSTALLED_APPS anda), dan nama dari model Django yang ingin anda gunakan sebagai model pengguna.
If you're starting a new project, you can set up a custom user model that\nbehaves identically to the default user model by subclassing\nAbstractUser:
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\nJangan lupa menunjuk AUTH_USER_MODEL ke itu. Lakukan ini sebelum membuat perpindahan apapun atau menjalankan manage.py migrate untuk pertama kalinya.
Juga, daftar model dalam admin.py aplikasi:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nChanging AUTH_USER_MODEL after you've created database tables is\npossible, but can be complex, since it affects foreign keys and many-to-many\nrelationships, for example.
Perubahan ini tidak dapat diselesaikan secara otomatis dan membutuhkan perbaikan secara manual skema anda, memindahkan data anda dari tabel user lama, dan kemungkinan secara manual memberlakukan kembali beberapa perpindahan. Lihat #25313 untuk ringkasan dari langkah-langkah.
\nKarena pembatasan dari fitur ketergantungan dinamis Django untuk model-model dapat ditukar, pengacuan model oleh AUTH_USER_MODEL harus dibuat di perpindahan pertama dari aplikasinya (biasanya dipanggil 0001_initial); sebaliknya, anda akan mempunyai masalah ketergantungan.
Sebagai tambahan, anda mungkin berjalan kedalam CircularDependencyError ketika menjalankan perpindahan anda sebagai Django tidak akan dapat secara otomatis memutus ketergantungan pada ketergantungan dinamis. Jika anda melihat kesalahan ini, anda harus memutuskan perulangan dengan memindahkan model bergantung pada model user anda kedalam perindahan kedua. (Anda dapat mencoba membuat dua model biasa yang memiliki ForeignKey ke setiap lainnya dan melihat bagaimana makemigrations mengatasi lingkaran ketergantungan jika anda ingin melihat bagaimana itu biasanya diselesaikan.)
AUTH_USER_MODELLink to this heading#Aplikasi dapat digunakan kembali tidak harus menerapkan penyesuaian model user. Sebuah proyek mungkin menggunakan banyak aplikasi, dan dua aplikasi dapat digunakan kembali yang menerapkan penyesuaian model user tidak dapat digunakan bersama-sama. Jika anda butuh menyimpan per informasi pengguna di aplikasi anda, gunakan ForeignKey atau OneToOneField pada settings.AUTH_USER_MODEL seperti yang digambarkan dibawah.
UserLink to this heading#Jika anda mengacu User secara langsung (sebagai contoh, dengan mengacu ke itu di foreign key), kode anda tidak akan bekerja di proyek dimana pengaturan AUTH_USER_MODEL telah berubah ke model user berbeda.
Daripada mengacu ke User secara langsung, anda harus mengacu modl user menggunakan django.contrib.auth.get_user_model(). Metode ini akan mengembalikan model user aktif saat ini -- penyesuaian model user jika satu adalah ditentukan, atau User sebaliknya.
Ketika anda menentukan foreign key atau hubungan many-to-many pada model pengguna, anda harus menentukan model penyesuaian menggunakan pengaturan AUTH_USER_MODEL. Sebagai contoh:
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nKetika terhubung ke sinyal yang dikirim oleh model User. anda harus menentukan penyesuaian model menggunakan pengaturan AUTH_USER_MODEL. Sebagai contoh:
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nSecara umum, itu paling mudah mengacu ke model user dengan pengaturan AUTH_USER_MODEL dalam kode yang dijalankan pada waktu impor, bagaimanapun, itu juga memungkinkan memanggil get_user_model() selagi Django mengimpor model, jadi anda dapat menggunakan models.ForeignKey(get_user_model(), ...).
Jika aplikasi anda dicobakan dengan banyak model user, menggunakan @override_settings(AUTH_USER_MODEL=...) sebagai contoh, dan anda meng cache hasil dari get_user_model() dalam sebuah variabel tingkat-variabel, anda mungkin butuh mendengarkan pada sinyal setting_changed untuk membersihkan cache. Sebagai contoh:
from django.apps import apps\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\nKetika anda memulai proyek anda dengabn model user penyesuaian, hentikan untuk mempertimbangkan jika ini pilihan tepat untuk proyek anda.
\nMenyimpan semua informasi terkait pengguna dalam satu model menghilangkan kebutuhan akan permintaan basisdata tambahan atau yang lebih kompleks untuk mengambil model terkait. Di sisi lain, mungkin lebih cocok untuk menyimpan informasi pengguna khusus aplikasi dalam model yang memiliki hubungan dengan model pengguna khusus anda. Itu memungkinkan setiap aplikasi menentukan persyaratan data penggunanya sendiri tanpa berpotensi bertentangan atau melanggar asumsi oleh aplikasi lain. Ini juga berarti bahwa anda akan menjaga model pengguna Anda sesederhana mungkin, fokus pada otentikasi, dan mengikuti persyaratan minimum yang Django harapkan untuk dipenuhi oleh model pengguna penyesuaian.
\nJika anda menggunakan backend pembuktian keaslian awal, kemudian model anda harus mempunyai bidang unik tunggal yang dapat digunakan untuk tujuan pencirian. Ini dapat berupa nama pengguna, sebuah alamat surel, atau atribut unik lainnya. Bidang nama pengguna tidak unik diizinkan jika anda menggunakan penyesuaian backend pembuktian keaslian yang dapat mendukungnya.
\nCara termudah untuk membangun selalu tunduk penyesuaian model user adalah mewarisi dari AbstractBaseUser. AbstractBaseUser menyediakan inti penerapan dari model user, termasuk sandi bercampur dan setel kembali sandi token. Anda harus kemudian menyediakan beberapa kunci penerapan rincian:
Sebuah string yang menjelaskan nama bidang pada model pengguna yang digunakan sebagai pengidentifikasi unik. Ini biasanya berupa nama pengguna, tetapi bisa juga berupa alamat surel, atau pengidentifikasi unik lainnya. Bidang harus unik (mis. memiliki unique=True ditetapkan dalam pengertiannya), kecuali jika anda menggunakan backend autentikasi khusus yang dapat mendukung nama pengguna tidak-unik.
Dalam contoh berikut, bidang identifier digunakan sebagai bidang pengenal:
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\nSebuah string menggambarkan nama dari bidang surel pada model User. Nilai ini dikembalikan oleh get_email_field_name().
Sebuah daftar dari nama bidang yang akan diminta ketika membuat sebuah pengguna melalui perintah pengelolaan createsuperuser. Pengguna akan diminta untuk menyediakan nilai untuk setiap bidang ini. Itu harus menyertakan bidang apapun yang blank adalah False atau tidak menentukan dan mungkin disertakan bidang tambahan anda ingin minta ketika sebuah pengguna dibuat secara interaktif. REQUIRED_FIELDS tidak mempunyai efek di bagian lagi dari Django, seperti membuat sebuah pengguna di admin.
Sebagai contoh, ini ada pengertian sebagian untuk model pengguna yang menentukan dua bidang wajib- tanggal lahir dan tinggi:
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nSebuah atribut boolean yang mengindikasikan apakah pengguna dianggap "aktif". Atribut ini disediakan sebagai sebuah atribut pada AbstractBaseUser awalan pada True. Bagaimana anda memilih menerapkan itu akan tergantung pada rincian dari backend otentifikasi yang anda pilih. Lihat dokumentasi dari is_active attribute on the built-in user model untuk rincian.
Pilihan. Penciri resmi lebih panjang untuk pengguna seperti nama penuh mereka. Jika diterapkan, ini muncul disamping nama pengguna dalam riwayat obyek dalam django.contrib.admin.
Pilihan. Pendek, penciri tidak resmi untuk pengguna seperti nama pertama mereka. Jika diterapkan, ini mengganti nama pengguna dalam salam sapa ke pengguna di kepala dari django.contrib.admin.
Atribut dan cara berikut tersedia pada setiap subkelas dari AbstractBaseUser:
Mengembalikan nilai dari bidang dicalonkan oleh USERNAME_FIELD.
Normalisasikan nama pengguna dengan memanggil normalize_username(). Jika anda menimpa cara ini, pastikan memanggil super() untuk menahan normalisasi.
Mengembalikan nama dari bidang surel ditentukan oleh atribut EMAIL_FIELD. Awalan pada 'email' jika EMAIL_FIELD tidak ditentukan.
Memberlakukan normalisasi Unicode NFKC pada nama pengguna sehingga nampak karakter mirip dengan titik kode Unicode berbeda dianggap mirip.
\nAtribut hanya-baca yang selalu True (sebagai lawan AnonymousUser.is_authenticated yang selalu False). Ini adalah cara untuk memberitahu jika pengguna telah diotentifikasi. Ini tidak berarti perizinan apapun dan tidak memeriksa jika pengguna adalah aktif atau mempunyai sesi sah. Meskipun secara biasa anda akan memeriksa atribut ini pada request.user untuk menemukan apakah itu telah dikumpulkan oleh AuthenticationMiddleware (mewakili pengguna masuk saat ini), anda harus mengetahui atribut ini adalah True untuk tiap instance User.
Atribut hanya-baca yaitu selalu False. Ini adalah jalan untuk membedakan obyek User and AnonymousUser. Umumnya, anda harus memilih menggunakan is_authenticated pada atribut ini.
Setel sandi pengguna ke deretan karakter mentah yang diberikan, merawat has sandi. Tidak menyimpan obyek AbstractBaseUser.
Ketika sandi mentah adalah None, sandi akan disetel ke sandi tidak biasa, seolah-olah set_unusable_password() digunakan.
Versi asinkron: acheck_password()
Mengembalikan True jika deretan karakter mentah yang diberikan adalah sandi benar untuk pengguna. (Ini merawat hash sandi dalam membuat perbandingan.)
Tandai pengguna sebagai mempunyai sandi tidak disetel. Ini tidak sama seperti memiliki deretan karakter kosong untuk sebuah sandi. check_password() untuk pengguna ini tidak akan pernah mengembalikan True. Tidak menyimpan obyek AbstractBaseUser.
Anda mungkin butuh ini jika otentifikasi untuk aplikasi anda memakan tempat terhadap sumber luar yang ada seperti pelipat LDAP.
\nMengembalikan False jika set_unusable_password() telah dipanggil untuk pengguna ini.
Mengembalikan nilai HMAC dari kolom kata sandi. Digunakan untuk Penghapusan sesi pada perubahan sandi.
\nMenghasilkan HMAC bidang kata sandi menggunakan SECRET_KEY_FALLBACKS. Digunakan oleh get_user().
AbstractUser subkelas AbstractBaseUser:
Normalisasikan surel dengan memanggil BaseUserManager.normalize_email(). Jika anda menimpa cara ini, pastikan memanggil super() untuk menahan normalisasi.
Anda juga harus menentukan pengelola khusus untuk model pengguna Anda. Jika model pengguna Anda mendefinisikan bidang username, email, is_staff, is_active, is_superuser, last_login, dan date_joined dengan bidang yang sama sebagai pengguna awalan Django, anda dapat memasang UserManager Django; namun, jika model pengguna anda mendefinisikan bidang yang berbeda, anda akan perlu mendefinisikan pengelola penyesuaian yang memperluas BaseUserManager menyediakan dua cara tambahan:
Sifat dari create_user() harus menerima bidang nama pengguna, ditambah semua bidang wajib sebagai argumen. Sebagai contoh, jika model pengguna anda menggunakan email sebagai bidang nama pengguna, dan mempunyai date_of_birth sebagai bidang wajib, kemudian create_user harus ditentukan sebagai:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nSifat dari create_superuser() harus menerima bidang nama pengguna, ditambah semua bidang wajib sebagai argumen. Sebagai contoh, jika model pengguna anda menggunakan email sebagai bidang nama pengguna, dan mempunyai date_of_birth sebagai bidang wajib, kemudian create_superuser harus ditentukan sebagai:
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\nUntuk ForeignKey di USERNAME_FIELD atau REQUIRED_FIELDS, metode ini menerima nilai dari to_field (the :attr:` ~django.db.models.Field.primary_key` secara default) dari instance yang ada.
BaseUserManager menyediakan cara kegunaan berikut:
Menormalkan alamat surel dengan menghuruf kecilkan bagian ranah dari alamat surel.
\nMengambil instance pengguna menggunakan isi dari bidang dicalonkan oleh USERNAME_FIELD.
User awal DjangoLink to this heading#Jika anda sepenuhnya puas dengan model User Django, tetapi anda ingin menambahkan beberapa informasi profil tambahan, Anda dapat membuat subkelas django.contrib.auth.models. AbstractUser dan tambahkan bidang profil khusus anda, meskipun kami menyarankan model terpisah seperti yang dijelaskan di Menentukan model pengguna penyesuaian. AbstractUser menyediakan implementasi penuh dari awalan User as an abstract model.
SIap-pakai Django forms dan views membuat pendapat tertentu tentang model user yang mereka bekerja dengannya.
\nBentuk berikut cocok dengan subkelas apapun dari AbstractBaseUser:
AuthenticationForm: Menggunakan bidang nama pengguna ditentukan oleh USERNAME_FIELD.
Formulir berikut membuat pendapat tentang model user dan dapat digunakan dengan adanya jika pendapat tersebut dipenuhi:
\nPasswordResetForm: Beranggapan bahwa model user mempunyai sebuah bidang yang menyimpan alamat surel pengguna dengan nama dikembalikan oleh get_email_field_name() (email secara awalan) yang dapat digunakan untuk mencirikan pengguna dan bidang boolean bernama is_active untuk mencegah penyetelan kembali sandi untuk pengguna tidak aktif.
Akhirnya, formulir berikut diikat pada User dan butuh ditulis kembali atau diperpanjang untuk bekerja dengan penyesuaian model user:
Jika model pengguna penyesuaian anda adalah subkelas dari AbstractUser, maka Anda dapat memperluas formulir ini dengan cara ini:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLink to this heading#Jika anda ingin penyesuaian model user anda juga bekerja dengan admin, model user anda harus menentukan beberapa atribut dan metode tambahan. Cara ini mengizinkan admin mengendalikan akses user ke isi admin:
\nMengembalikan True jika pengguna diizinkan mempunyai akses ke situs admin
Mengembalikan True jika akun pengguna saat ini aktif.
Mengembalikan True jika pengguna mempunyai perizinan nama. Jika obj disediakan, perizinan butuh diperiksa terhadap instace obyek tertentu.
Mengembalikan True jika pengguna mempunyai perizinan untuk mengakses model pada aplikasi yang diberikan.
Anda akan juga butuh mendaftarkan model pengguna penyesuaian anda dengan admin. Jika model pengguna penyesuaian anda memperpanjang django.contrib.auth.models.AbstractUser, anda dapat menggunakan kelas django.contrib.auth.admin.UserAdmin yang ada dari Django. Bagaimanapun, jika model pengguna anda memperpanjang AbstractBaseUser, anda akan butuh menentukan kelas ModelAdmin penyesuaian. Itu memungkinkan untuk mensubkelaskan awalan django.contrib.auth.admin.UserAdmin; bagaimanapun, anda akan butuh menimpa tiap pengertian yang mengacu ke bidang pada django.contrib.auth.models.AbstractUser yang tidak pada kelas pengguna penyesuaian anda.
Untuk membuatnya lebih mudah untuk menyertakan kerangka kerja perizinan Django kedalam kelas user anda sendiri, Django menyediakan PermissionsMixin. Ini adalah model abstrak anda dapat sertakan di susunan tingkat kelas untuk model user anda. memberikan anda semua metode dan bidang basisdata yang diperlukan untuk mendukung model perizinan Django.
PermissionsMixin menyediakan cara dan atribut berikut:
Boolean. Menunjuk bahwa pengguna ini mempunyai semua perizinan tanpa secara jelas menetapkan mereka.
\nMengembalikan sekumpulan string perizinan yang pengguna miliki secara langsung.
\nJika obj dilewatkan, hanya mengembalikan perizinan pengguna untuk objek khusus ini.
Mengembalikan deretan karakter kumpulan perizinan yang pengguna punyai, melalui kelompok mreka.
\nJika obj diloloskan, hanya mengembalikan perizinan kelompok untuk obyek tertentu ini.
Mengembalikan sekumpulan deretan karakter perizinan yang pengguna punyai, kedua melalui perizinan kelompok dan pengguna.
\nJika obj diloloskan. hanya mengembalikan perizinan untuk obyek tertentu ini.
Mengembalikan True jika pengguna memiliki perijinan yang ditentukan, dimana perm dalam bentuk "<app label>.<permission codename>" (lihat permissions). Jika User.is_active dan is_superuser keduanya True, metode ini selalu mengembalikan True.
Jika obj diloloskan, metode ini tidak akan memeriksa untuk sebuah perizinan untuk model, tetapi untuk obyek tertentu ini.
Mengembalikan True jika pengguna mempunyai setiap dari perijinan yang ditentukan, dimana setiap perijinan dalam bentuk "<app label>.<permission codename>". Jika User.is_active dan is_superuser keduanya True, metode ini selalu mengembalikan True.
Jika obj diloloskan, metode ini tidak akan memeriksa untuk perizinan-perizinan untuk model, tetapi untuk obyek tertentu.
Mengembalikan True jika pengguna memiliki izin dalam paket yang diberikan (label aplikasi Django). Jika User.is_active dan is_superuser keduanya True, metode ini selalu mengembalikan True.
Satu batasan dari penyesuaian model user adalah bahwa memasang penyesuaian model user akan memutus tiap model proxy memperpanjang User. Model proxy harus berdasarkan pada kelas dasar nyata; dengan menentukan penyesuaian model user, anda memindah kemampuan dari Django untuk menciri yang handal kelas dasar.
Jika proyek anda menggunakan model proxy, anda harus salah satu merubah proxy untuk memperpanjang model yser yang digunakan di proyek anda, atau menggabungkan kebiasaan proxy anda kedalam subkelas User.
Berikut adalah contoh aplikasi pengguna khusus yang sesuai dengan admin. Model pengguna ini menggunakan alamat email sebagai nama pengguna, dan memiliki tanggal lahir yang diperlukan; itu tidak memberikan pemeriksaan izin di luar bendera admin pada akun pengguna. Model ini akan cocok dengan semua formulir dan tampilan autentikasi bawaan, kecuali untuk formulir pembuatan pengguna. Contoh ini mengilustrasikan bagaimana sebagian besar komponen bekerja sama, namun tidak dimaksudkan untuk disalin langsung ke proyek untuk penggunaan produksi.
Kode ini akan semua tinggal di berkas models.py untuk aplikasi otentifikasi penyesuaian:
from django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError("Users must have an email address")\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password=None):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name="email address",\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = "email"\n REQUIRED_FIELDS = ["date_of_birth"]\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nKemudian, untuk mendaftar model pengguna penyesuaian dengan admin Django, kode berikut akan diwajibkan di berkas admin.py aplikasi:
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\nfrom django.core.exceptions import ValidationError\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\n\n class Meta:\n model = MyUser\n fields = ["email", "date_of_birth"]\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ["email", "date_of_birth", "is_admin"]\n list_filter = ["is_admin"]\n fieldsets = [\n (None, {"fields": ["email", "password"]}),\n ("Personal info", {"fields": ["date_of_birth"]}),\n ("Permissions", {"fields": ["is_admin"]}),\n ]\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = [\n (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\nAkhirnya, tentukan model penyesuaian sebagai model pengguna awal untuk proyek anda menggunakan pengaturan AUTH_USER_MODEL di settings.py anda:
AUTH_USER_MODEL = "customauth.MyUser"\n