Pembuktian keaslian yang datang dengan Django adalah cukup bagus untuk kasus umum, tetapi anda mungkin tidak butuh memenuhi dengan awal out-of-the-box. Untuk menyesuaiakan pembuktian keaslian ke proyek anda butuh melibatkan pemahaman titik apa dari sistem disediakan dapat di perpanjang atau diganti. Dokumen ini menyediakan rincian tentang bagaimana sistem pembuktian keaslian dapat di sesuaikan.
\nAuthentication backends menyediakan sistem dapat diperpanjang untuk ketika nama pengguna dan sandi disimpan dengan model User butuh diperiksa keasliannya terhadap layanan berbeda dari awa Django.
\nAnda dapat memberikan model anda perizinan perizinan disesuaikan yang dapat diperiksa melalui sistem pemeriksaan keaslian Django.
\nAnda dapat extend User model awal, atau substitute model disesuaikan yang lengkap.
\nMungkin ada kali anda harus butuh mengait ke dalam sumber pembuktian keaslian lain -- yaitu, sumber lain dari nama pengguna dan sandi atau cara 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 mengesampingkan skema berbasis-basisdata awal Django, atau anda dapat menggunakan sistem awal untuk dipasangkan dengan sistem lain.
\nLihat acuan backend pembuktian keaslian untuk informasi pada backend pembuktian keaslian 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 cara 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']\nItu adalah backend pembuktian keaslian dasar yang memeriksa basisdata pengguna Django dan permintaan perizinan terpasang-tetap. Dia tidak menyediakan perlindungan terhadap serangan paksa brutal melalui mekanisme pembatasan apapun. Anda dapat salah satu menerapkan mekanisme pembatasan laju anda sendiri di backend pembuktian keaslian penyesuaian, atau menggunakan mekanisme yang disediakan oleh kebanyakan peladen Jaringan.
\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 pembuktian keaslian adalah sebuah kelas yang menerapkan dua cara dibutuhkan: get_user(user_id) dan authenticate(**credentials), dan juga kumpulan dari pilihan perizinan terhubung cara pembuktian keaslian.
Cara get_user mengambil user_id -- yng dapat berupa nama pengguna, ID basisdata atau apapun, tetapi harus menjadu primary key dari obyek User anda -- dan mengembalikan obyek User.
Cara authenticate mengambil mandat sebagai argumen kata kunci. Kebanyakan dari waktu, dia akan kelihatan seperti ini:
class MyBackend(object):\n def authenticate(self, username=None, password=None):\n # Check the username/password and return a User.\n ...\nTetapi itu dapat juga membuktikan keaslian sebuah token, seperti begitu:
\nclass MyBackend(object):\n def authenticate(self, 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.
Admin Django erat ke Django Obyek User. Cara terbaik berurusan dengna ini adalah membuat obyek user Django untuk setiap pengguna yang ada untuk backend anda (sebagai contoh dalam direktori LDAP, basisdata SQL eksternal anda, dll.) Anda dapat salah satu menulis tulisan untuk melakukannya terlebih dahulu, atau cara authenticate anda dapat melakukannya pertama kali pengguna masuk.
Ini adalah sebuah contoh yang membuktikan keaslian variabel terhdap nama pengguna dan sandi ditentukan dalam berkas settings.py anda dan membuat sebuah obyek User Django pertama kali pengguna dibuktikan keaslian:
from django.conf import settings\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\nclass SettingsBackend(object):\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, 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. Note that we can set password\n # to anything, because it won't be checked; the password\n # from settings.py will.\n user = User(username=username, password='get from settings.py')\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.
Model task contoh ini membuat tiga perizinan penyesuaian, yaitu, tindakan pengguna dapat atau tidak dapat dilakukan dengan permintaan Task, khusus pada apliaksi anda:
\nclass Task(models.Model):\n ...\n class Meta:\n permissions = (\n ("view_task", "Can see available tasks"),\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 ini dilakukan adalah membuat perizinan tambahan ketika anda menjalankan manage.py migrate (fungsi yang membuat perizinan terhubung ke sinyal post_migrate). Kode anda bertanggung jawab dari pemeriksaan nilai perizinan ini ketika sebuah pengguna mencoba mengakses fungsionalitas disediakan oleh aplikasi (melihat tugas, merubah keadaan dari tugas, menutup tugas.) Melanjutkan contoh diatas, pemeriksaan berikut jika sebuah pengguna mungkin melihat tugas:
user.has_perm('app.view_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\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nMengganggap Pegawai Fred Smith yang ada yang mempunyai kedua model User dan Employee, anda dapat mengakses informasi terkait menggunakan standar Django ketentuan model terkait:
\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# 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# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = (EmployeeInline, )\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nModel profil ini tidak khusus di jalan apapun - mereka hanya model Django yang terjadi untuk mempunyai kaitan satu-ke-satu dengan model User. Seperti, mereka tidak mendapatkan otomatis dibuat ketika pengguna dibuat, tetapi django.db.models.signals.post_save dapat digunakan untuk membuat atau memperbaharui model terkait sewajarnya.
Catat bahwa menggunakan hasil model terkait di tambahan permintaan atau penggabungan untuk mendapatkan data terkait, dan tergantung pada kebutuhan anda mengganti model User dan menambahkan bidang terkait mungkin pilihan terbaik anda. Bagaimanapun tautan terkait ke model User awal 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 dipasang tetap Django tidak selalu sesuai. Sebagai contoh, pada beberapa situs akan masuk akal menggunakan sebauh alamat surel sebagai token pencirian daripada nama pengguna.
Django mengizinkan anda untuk mengesampingkan model User awal dengan menyediakan nilai untuk pengaturan AUTH_USER_MODEL yang mengacu sebuah model penyesuaian:
AUTH_USER_MODEL = 'myapp.MyUser'\nPasangan titik ini menggambarkan nama dari aplikasi Django (yang harus berada di INSTALLED_APPS), dan nama dari model Django yang anda harapkan untuk digunakan sebagai model User anda.
UserLink to this heading#If you reference User directly (for\nexample, by referring to it in a foreign key), your code will not work in\nprojects where the AUTH_USER_MODEL setting has been changed to a\ndifferent User model.
Instead of referring to User directly,\nyou should reference the user model using\ndjango.contrib.auth.get_user_model(). This method will return the\ncurrently active User model -- the custom User model if one is specified, or\nUser otherwise.
Ketika anda menentukan foreign key atau hubungan many-to-many pada model User, anda harus menjelaskan penyesuaian model menggunakan pengaturan AUTH_USER_MODEL. Sebagai contoh:
from django.conf import settings\nfrom django.db import models\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\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nSecara umum, anda harus mengacu model User dengan pengaturan AUTH_USER_MODEL di kode yang dijalankan pada waktu impor. get_user_model() hanya bekerja sekali ketika Django telah mengimpor semua model.
UserLink to this heading#Django mengharapkan model User penyesuaian anda memenuhi persyaratan minimal.
\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, sebauh alamat surel, atau atribut unik lainnya. Bidang nama pengguna tidak unik diizinakn jika anda menggunakan penyesuaian backend pembuktian keaslian yang dapat mendukungnya.
Model anda harus menyediakan cara terbaik utnuk mengalamatkan pengguna dalam bentuk "short" and "long". Penafsiran paling umum dari ini akan digunakan nama diberikan pengguna sebagai penciri "short", dan nama lengkap pengguna sebagai penciri "long". Bagaimanapun, tidak ada batasan pada apa yang duca cara ini kembalikan - jika anda ingin, mereka dapat mengembalikan nilai sama yang tepat.
The easiest way to construct a compliant custom User model is to inherit from\nAbstractBaseUser.\nAbstractBaseUser provides the core\nimplementation of a User model, including hashed passwords and tokenized\npassword resets. You must then provide some key implementation details:
A string describing the name of the field on the User model that is\nused as the unique identifier. This will usually be a username of some\nkind, but it can also be an email address, or any other unique\nidentifier. The field must be unique (i.e., have unique=True set\nin its definition), unless you use a custom authentication backend that\ncan support non-unique usernames.
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'\nUSERNAME_FIELD now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A list of the field names that will be prompted for when creating a\nuser via the createsuperuser management command. The user\nwill be prompted to supply a value for each of these fields. It must\ninclude any field for which blank is\nFalse or undefined and may include additional fields you want\nprompted for when a user is created interactively.\nREQUIRED_FIELDS has no effect in other parts of Django, like\ncreating a user in the admin.
Sebagai contoh, ini adalah pengertian sebagian untuk model User yang menentukan dua bidang diwajibkan - tanggal dari kelahiran dan tinggi:
class MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ['date_of_birth', 'height']\nREQUIRED_FIELDS now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A boolean attribute that indicates whether the user is considered\n"active". This attribute is provided as an attribute on\nAbstractBaseUser defaulting to True. How you choose to\nimplement it will depend on the details of your chosen auth backends.\nSee the documentation of the is_active attribute on the built-in\nuser model for details.
A longer formal identifier for the user. A common interpretation\nwould be the full name of the user, but it can be any string that\nidentifies the user.
\nA short, informal identifier for the user. A common interpretation\nwould be the first name of the user, but it can be any string that\nidentifies the user in an informal way. It may also return the same\nvalue as django.contrib.auth.models.User.get_full_name().
The following methods are available on any subclass of\nAbstractBaseUser:
Mengembalikan nilai dari bidang dicalonkan oleh USERNAME_FIELD.
Always returns False. This is a way of differentiating\nfrom AnonymousUser objects.\nGenerally, you should prefer using\nis_authenticated() to this\nmethod.
Always returns True. This is a way to tell if the user has been\nauthenticated. This does not imply any permissions, and doesn't check\nif the user is active - it only indicates that the user has provided a\nvalid username and password.
Sets the user's password to the given raw string, taking care of the\npassword hashing. Doesn't save the\nAbstractBaseUser object.
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
Returns True if the given raw string is the correct password for\nthe user. (This takes care of the password hashing in making the\ncomparison.)
Marks the user as having no password set. This isn't the same as\nhaving a blank string for a password.\ncheck_password() for this user\nwill never return True. Doesn't save the\nAbstractBaseUser object.
You may need this if authentication for your application takes place\nagainst an existing external source such as an LDAP directory.
\nReturns False if\nset_unusable_password() has\nbeen called for this user.
Mengembalikan nilai HMAC dari kolom kata sandi. Digunakan untuk Session invalidation on password change.
\nYou should also define a custom manager for your User model. If your\nUser model defines username, email, is_staff, is_active,\nis_superuser, last_login, and date_joined fields the same as\nDjango's default User, you can just install Django's\nUserManager; however, if your User\nmodel defines different fields, you will need to define a custom manager that\nextends BaseUserManager providing two\nadditional methods:
The prototype of create_user() should accept the username field,\nplus all required fields as arguments. For example, if your user model\nuses email as the username field, and has date_of_birth as a\nrequired field, then create_user should be defined as:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nThe prototype of create_superuser() should accept the username\nfield, plus all required fields as arguments. For example, if your user\nmodel uses email as the username field, and has date_of_birth\nas a required field, then create_superuser should be defined as:
def create_superuser(self, email, date_of_birth, password):\n # create superuser here\n ...\nTidak seperti create_user(), create_superuser() harus membutuhkan pemanggil untuk menyedianan sebuah sandi.
BaseUserManager menyediakan cara kegunaan berikut:
Normalizes email addresses by lowercasing the domain portion of the\nemail address.
\nRetrieves a user instance using the contents of the field\nnominated by USERNAME_FIELD.
Returns a random password with the given length and given string of\nallowed characters. Note that the default value of allowed_chars\ndoesn't contain letters that can cause user confusion, including:
i, l, I, and 1 (huruf kecil i, huruf kecil L, huruf besar i, dan angka satu)
o, O, and 0 (huruf kecil o, huruf besar o, dan nol)
UserLink to this heading#If you're entirely happy with Django's User\nmodel and you just want to add some additional profile information, you could\nsimply subclass django.contrib.auth.models.AbstractUser and add your\ncustom profile fields, although we'd recommend a separate model as described in\nthe "Model design considerations" note of Menentukan penyesuaian model User.\nAbstractUser provides the full implementation of the default\nUser as an abstract model.
Django's built-in forms and views make certain assumptions about the user model that they\nare working with.
\nBentuk berikut cocok dengan subkelas apapun dari AbstractBaseUser:
AuthenticationForm: Menggunakan bidang nama pengguna ditentukan oleh USERNAME_FIELD.
The following forms make assumptions about the user model and can be used as-is\nif those assumptions are met:
\nPasswordResetForm: Assumes that the user\nmodel has a field named email that can be used to identify the user and a\nboolean field named is_active to prevent password resets for inactive\nusers.
Finally, the following forms are tied to\nUser and need to be rewritten or extended\nto work with a custom user model:
If your custom user model is a simple subclass of AbstractUser, then you\ncan extend these forms in this manner:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\nclass CustomUserCreationForm(UserCreationForm):\n\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ('custom_field',)\ndjango.contrib.adminLink to this heading#If you want your custom User model to also work with Admin, your User model must\ndefine some additional attributes and methods. These methods allow the admin to\ncontrol access of the User to admin content:
\nMengembalikan True jika pengguna diizinkan mempunyai akses ke situs admin
Mengembalikan True jika akun pengguna saat ini aktif.
Returns True if the user has the named permission. If obj is\nprovided, the permission needs to be checked against a specific object\ninstance.
Mengembalikan True jika pengguna mempunyai perizinan untuk mengakses model pada aplikasi yang diberikan.
You will also need to register your custom User model with the admin. If\nyour custom User model extends django.contrib.auth.models.AbstractUser,\nyou can use Django's existing django.contrib.auth.admin.UserAdmin\nclass. However, if your User model extends\nAbstractBaseUser, you'll need to define\na custom ModelAdmin class. It may be possible to subclass the default\ndjango.contrib.auth.admin.UserAdmin; however, you'll need to\noverride any of the definitions that refer to fields on\ndjango.contrib.auth.models.AbstractUser that aren't on your\ncustom User class.
To make it easy to include Django's permission framework into your own User\nclass, Django provides PermissionsMixin.\nThis is an abstract model you can include in the class hierarchy for your User\nmodel, giving you all the methods and database fields necessary to support\nDjango's permission model.
PermissionsMixin menyediakan cara dan atribut berikut:
Boolean. Designates that this user has all permissions without\nexplicitly assigning them.
\nReturns a set of permission strings that the user has, through their\ngroups.
\nIf obj is passed in, only returns the group permissions for\nthis specific object.
Returns a set of permission strings that the user has, both through\ngroup and user permissions.
\nIf obj is passed in, only returns the permissions for this\nspecific object.
Returns True if the user has the specified permission, where\nperm is in the format "<app label>.<permission codename>" (see\npermissions). If the user is inactive, this method will\nalways return False.
If obj is passed in, this method won't check for a permission for\nthe model, but for this specific object.
Returns True if the user has each of the specified permissions,\nwhere each perm is in the format\n"<app label>.<permission codename>". If the user is inactive,\nthis method will always return False.
If obj is passed in, this method won't check for permissions for\nthe model, but for the specific object.
Returns True if the user has any permissions in the given package\n(the Django app label). If the user is inactive, this method will\nalways return False.
One limitation of custom User models is that installing a custom User model\nwill break any proxy model extending User.\nProxy models must be based on a concrete base class; by defining a custom User\nmodel, you remove the ability of Django to reliably identify the base class.
If your project uses proxy models, you must either modify the proxy to extend\nthe User model that is currently in use in your project, or merge your proxy's\nbehavior into your User subclass.
\nHere is an example of an admin-compliant custom user app. This user model uses\nan email address as the username, and has a required date of birth; it\nprovides no permission checking, beyond a simple admin flag on the user\naccount. This model would be compatible with all the built-in auth forms and\nviews, except for the User creation forms. This example illustrates how most of\nthe components work together, but is not intended to be copied directly into\nprojects for production use.
This code would all live in a models.py file for a custom\nauthentication app:
from django.db import models\nfrom django.contrib.auth.models import (\n BaseUserManager, AbstractBaseUser\n)\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):\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 get_full_name(self):\n # The user is identified by their email address\n return self.email\n\n def get_short_name(self):\n # The user is identified by their email address\n return self.email\n\n def __str__(self): # __unicode__ on Python 2\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\nThen, to register this custom User model with Django's admin, the following\ncode would be required in the app's admin.py file:
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\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 password1 = forms.CharField(label='Password', widget=forms.PasswordInput)\n password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)\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 forms.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(UserCreationForm, self).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 password hash display field.\n """\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')\n\n def clean_password(self):\n # Regardless of what the user provides, return the initial value.\n # This is done here, rather than on the field, because the\n # field does not have access to the initial value\n return self.initial["password"]\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 (None, {\n 'classes': ('wide',),\n 'fields': ('email', 'date_of_birth', 'password1', 'password2')}\n ),\n )\n search_fields = ('email',)\n ordering = ('email',)\n filter_horizontal = ()\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)\nFinally, specify the custom model as the default user model for your project\nusing the AUTH_USER_MODEL setting in your settings.py:
AUTH_USER_MODEL = 'customauth.MyUser'\n