Dokumen ini menjelaskan penggunaan dari sistem otentifikasi Django di konfigurasi awalannya. Konfigurasi ini telah berkembang untuk melayani kebutuhan proyek paling umum, menangani jangkauan luas beralasan dari tugas, dan mempunyai penerapan cermat dari sandi dan perizinan. Untuk proyek dimana otentifikasi butuh berbeda dari awalan, Django mendukung extension and customization luas dari otentifikasi.
Otentifikasi Django menyediakan kedua otentifikasi dan otorisasi bersama-sama dan umumnya mengacu pada sebagai sistem otentifikasi, ketika fitur ini agak digabungkan.
User
¶Obyek User
adalah inti dari sistem autentifikasi. Mereka khususnya mewakili orang berinteraksi dengan situs anda dan digunakan untuk mengadakan hal-hal seperti membatasi akses, mendaftarkan profil pengguna, menyatukan isi dengan pembuat dll. Hanya satu kelas dari pengguna yang ada di otentifikasi kerangka kerja Django, yaitu, 'superusers'
atau admin pengguna 'staff'
hanya obyek user dengan sekumpulan atribut khusus, bukan kelas-kelas berbeda dari obyek user.
Atribut utama dari pengguna awal adalah:
Lihat :class:`full API documentation <django.contrib.auth.models.User>`untuk acuan penuh, dokumentasi yang mengikuti lebih berorientasi tugas.
Cara paling langsung untuk membuat pengguna adalah dengan menggunakan fungsi pembantu create_user()
yang disertakan:
>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user("john", "lennon@thebeatles.com", "johnpassword")
# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = "Lennon"
>>> user.save()
Jika anda mempunai admin Django dipasang, anda dapat juga create users interactively.
Buat pengguna super menggunakan perintah createsuperuser
:
$ python manage.py createsuperuser --username=joe --email=joe@example.com
...\> py manage.py createsuperuser --username=joe --email=joe@example.com
Anda akan diminta untuk sandi. Setelah anda memasukkan satu, pengguna akan membuat dengan segera. Jika anda membiarkan mati pilihan --username
atau --email
, itu akan meminta anda untuk nilai-nilai tersebut.
Django tidak menyimpan sandi (teks bersih) mentah pada model user, tetapi hanya campuran (lihat documentation of how passwords are managed untuk rincian penuh). Karena dari ini, jangan mencoba untuk mengubah atribut sanddi dari pengguna secara langsung. Ini adalah mengapa fungsi pembantu digunakan ketika membuat pengguna.
Untuk merubah sandi pengguna, anda mempunyai beebrapa pilihan:
manage.py changepassword *username*
menawarkan metode dari merubah sandi pengguna dari baris perintah. Itu mendorong anda merubah sandi dari pengguna yang diberikan yang anda harus masukkan dua kali. Jika mereka kedua cocok, sandi baru akan berubah segera. Jika anda tidak memasok pengguna, perintah akan berusaha merubah sandi yang nama pengguna cocok dengan pengguna sistem saat ini.
Anda dapat juga merubah sandi secara program, menggunakan set_password()
:
>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username="john")
>>> u.set_password("new password")
>>> u.save()
Jika anda mempunyai admin Django terpasang, anda dapat juga merubah sandi pengguna pada halaman admin sistem pembuktian keaslian.
Django juga menyediakan views dan forms yang mungkin digunakan untuk mengizinkan pengguna merubah sandi mereka sendiri.
Merubah sandi pengguna akan keluar semua sesi mereka. Lihat Penghapusan sesi pada perubahan sandi untuk rincian.
authenticate
(request=None, **credentials)¶Gunakan authenticate()
untuk memeriksa kumpulan dari mandat. Itu mengambil mandat sebagai argumen kata kunci, username
dan password
untuk kasus awal, periksa mereka kembali setiap authentication backend, dan kembalikan obyek User
jika mandat sah untuk backend. Jika mandat tidak sah untuk setiap backend atau jika backend menampilkan PermissionDenied
, itu mengembalikan None
. Sebagai contoh:
from django.contrib.auth import authenticate
user = authenticate(username="john", password="secret")
if user is not None:
# A backend authenticated the credentials
...
else:
# No backend authenticated the credentials
...
request
adalah sebuah pilihan HttpRequest
yang dilewatkan pada metode authenticate()
dari backend autentifikasi.
Catatan
Ini adalah cara tingkat bawah untuk mengautentifikasi kumpulan dari kepercayaan; sebagai contoh, itu digunakan oleh RemoteUserMiddleware
. Meskipun anda sedang menulis sisten autentifikasi anda sendiri, anda mungkin tidak menggunakan ini. Daripada jika anda sedang mencari cara untuk masuk seorang pengguna, gunakan LoginView
.
Django hadir dengan sistem perizinan bawaan. Ini menyediakan cara untuk memberikan izin kepada pengguna dan grup pengguna tertentu.
Digunakan oleh situs admin Django, tetapi anda dipersilahkan menggunakannya di kode anda sendiri.
Situs admin Django menggunakan perizinan sebagai berikut:
Izin dapat diatur tidak hanya per jenis objek, tetapi juga per instance objek tertentu. Dengan menggunakan has_view_permission()
, has_add_permission()
, has_change_permission()
dan metode has_delete_permission()
disediakan oleh kelas ModelAdmin
, dimungkinkan untuk menyesuaikan izin untuk instance objek berbeda dari jenis yang sama.
Obyek User
mempunyai dua bidang many-to-many: groups
dan user_permissions
. Obyek User
dapat mengakses obyek terkait mereka di cara yang sama seperti yang Django model lain:
myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()
Ketika django.contrib.auth
terdaftar di INSTALLED_APPS
pengaturan anda, ini akan memastikan bahwa empat izin awalan -- tambah, ubah, hapus, dan lihat -- dibuat untuk setiap model Django yang ditentukan dalam satu dari aplikasi yang anda pasang.
Perizinan ini akan dibuat ketika anda menjalankan manage.py migrate
; pertama kali anda menjalankan migrate
setelah menambahkan django.contrib.auth
pada INSTALLED_APPS
, perizinan awalan akan dibuat untuk semua model sebelumnya-terpasang, sama halnya untuk tiap model baru sedang dipasang pada waktu itu. Kemudian, itu akan membuat perizinan awalan untuk model baru setiap kali anda menjalankan manage.py migrate
(fungsi yang membuat perizinan adalah terhubung ke sinyal post_migrate
).
Menganggap anda memiliki sebuah aplikasi dengan app_label
foo
dan model bernama Bar
, pada percobaan untuk perizinan dasar anda harus gunakan:
user.has_perm('foo.add_bar')
user.has_perm('foo.change_bar')
user.has_perm('foo.delete_bar')
user.has_perm('foo.view_bar')
Model Permission
jarang diakses secara langsung.
Model django.contrib.auth.models.Group
adalah cara umum dari mengkategorikan pengguna sehingga anda dapat memberlakukan perizinan, atau beberapa label lain, ke penggun tersebut. Seorang pengguna dapat milik ke tiap sejumlah kelompok.
Seorang pengguna di kelompok secara otomatis mempunyai perizinan diberikan ke kelompok itu. Sebagai contoh, jika kelompok Site editors
mempunyai perizinan can_edit_home_page
, tiap pengguna di kelompok itu akan mempunyai perizinan itu.
Diluar perizinan, kelompok adalah cara nyaman untuk mengkategorikan pengguna untuk memberikan mereka beberapa label, atau memperpanjang kegunaan. Sebagai contoh, anda dapat membuat kelompok 'Special users'
, dan anda dapat menulis kode yang dapat, katakan, memberikan mereka akses ke bagian hanya-anggota dari situs anda, atau mengirim mereka pesan surel hanya-pesan.
Selagi custom permissions dapat ditentukan dalam kelas Meta
model, anda dapat juga membuat perizinan secara langsung. Sebagai contoh, anda dapat membuat perizinan can_publish
untuk model BlogPost
di myapp
:
from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType
content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
codename="can_publish",
name="Can Publish Posts",
content_type=content_type,
)
Perizinan dapat kemudian diberikan pada User
melalui atribut user_permissions
nya atau ke Group
melalui atribut permissions
nya.
Model proxy membutuhkan tipe kontennya sendiri
Jika anda ingin membuat permissions for a proxy model, lewatkan for_concrete_model=False
ke ContentTypeManager.get_for_model()
untuk mendapatkan ContentType
sesuai:
content_type = ContentType.objects.get_for_model(
BlogPostProxy, for_concrete_model=False
)
Perizinan tembolok ModelBackend
pada obyek user setelah pertama kali mereka butuh diambil untuk pemeriksaan perizinan. Ini adalah khususnya baik untuk siklus tanggapan-permintaan sejak perizinan tidak secara khusus memeriksa segera setelah mereka sitambahkan (dalam admin, sebagai contoh). Jika anda menambahkan perizinan dan memeriksa mereka segera setelahnya, dalam percobaan atau tampilan sebagai contoh, pemecahan termudah adalah mengambil kembali dari basisdata. Sebagai contoh:
from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404
from myapp.models import BlogPost
def user_gains_perms(request, user_id):
user = get_object_or_404(User, pk=user_id)
# any permission check will cache the current set of permissions
user.has_perm("myapp.change_blogpost")
content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.get(
codename="change_blogpost",
content_type=content_type,
)
user.user_permissions.add(permission)
# Checking the cached permission set
user.has_perm("myapp.change_blogpost") # False
# Request new instance of User
# Be aware that user.refresh_from_db() won't clear the cache.
user = get_object_or_404(User, pk=user_id)
# Permission cache is repopulated from the database
user.has_perm("myapp.change_blogpost") # True
...
Model proxy bekerja dengan cara yang persis sama dengan model konkret. Izin dibuat menggunakan jenis isi sendiri dari model proxy. Model proxy tidak mewarisi izin dari model berwujud yang mereka subkelaskan
class Person(models.Model):
class Meta:
permissions = [("can_eat_pizzas", "Can eat pizzas")]
class Student(Person):
class Meta:
proxy = True
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]
>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
... user.user_permissions.add(permission)
...
>>> user.has_perm("app.add_person")
False
>>> user.has_perm("app.can_eat_pizzas")
False
>>> user.has_perms(("app.add_student", "app.can_deliver_pizzas"))
True
Django menggunakan sessions dan middleware untuk menghubungkan sitem otentifikasi kedalam request objects
.
Ini menyediakan sebuah atribut request.user
pada setiap permintaan yang mewakili pengguna saat ini. Jika pengguna saat ini belum masuk, atribut ini akan disetel ke sebuah instance dari AnonymousUser
, sebaliknya itu akan berupa sebuah instance dari User
.
Anda dapat memberitahu mereka selain dengan is_authenticated
, seperti begitu
if request.user.is_authenticated:
# Do something for authenticated users.
...
else:
# Do something for anonymous users.
...
Jika anda mempunyai pengguna terotentifikasi anda ingin lampirkan ke sesi saat ini - ini dilakukan dengan fungsi login()
.
login
(request, user, backend=None)¶Untuk pengguna masuk, dari tampilan, gunakan login()
. Itu mengambil sebuah obyek HttpRequest
dan sebuah obyek User
. login()
menyimpan ID pengguna di sesi, menggunakan kerangka kerja sesi Django.
Catat bahwa tiap data disetel selama sesi anonim dipertahankan di sesi setelah pengguna masuk.
Contoh ini menunjukkan bagaimana anda mungkin menggunakan kedua authenticate()
dan login()
:
from django.contrib.auth import authenticate, login
def my_view(request):
username = request.POST["username"]
password = request.POST["password"]
user = authenticate(request, username=username, password=password)
if user is not None:
login(request, user)
# Redirect to a success page.
...
else:
# Return an 'invalid login' error message.
...
Ketika seorang pengguna masuk, ID pengguna dan backend yang telah digunakan untuk autentifikasi disimpan dalam sesi pengguna. Ini mengizinkan authentication backend sama untuk mengambil rincian pengguna pada permintaan akan datang. Backend autentifikasi untuk menyimpan sesi dipilih sebagai berikut:
backend
pilihan, jika disediakan.user.backend
, jika hadir. Ini mengizinkan memasangkan authenticate()
dan login()
: authenticate()
menyetel atribut user.backend
pada obyek user dia kembalikan.backend
dalam AUTHENTICATION_BACKENDS
, jika hanya ada satu.Di kasus 1 dan 2, nilai dari argumen backend
atau atribut user.backend
harus di impor bertitik jalur deretan karakter (seperti yang ditemukan di AUTHENTICATION_BACKENDS
), bukan kelas backend sebenarnya.
logout
(request)¶Untuk keluar pengguna yang telah masuk melalui django.contrib.auth.login()
, gunakan django.contrib.auth.logout()
dalam tampilan anda. Itu mengambil sebuah obyek HttpRequest
dan tidak nilai mempunyai kembalian. Contoh:
from django.contrib.auth import logout
def logout_view(request):
logout(request)
# Redirect to a success page.
Catat bahwa logout()
tidak melempar kesalahan apapun jika pengguna tidak masuk.
Saat Anda memanggil logout()
, data sesi untuk permintaan saat ini sepenuhnya dibersihkan. Semua data yang ada dihapus. Ini untuk mencegah orang lain menggunakan peramban web yang sama untuk masuk dan memiliki akses ke data sesi pengguna sebelumnya. Jika anda ingin memasukkan sesuatu ke dalam sesi yang akan tersedia untuk pengguna segera setelah keluar, lakukan itu setelah memanggil django.contrib.auth.logout()
.
Cara mentah untuk membatasi akses ke halaman adalah dengan memeriksa request.user.is_authenticated
dan mengarahkan ulang ke halaman login:
from django.conf import settings
from django.shortcuts import redirect
def my_view(request):
if not request.user.is_authenticated:
return redirect(f"{settings.LOGIN_URL}?next={request.path}")
# ...
...atau menampilkan pesan kesalahan:
from django.shortcuts import render
def my_view(request):
if not request.user.is_authenticated:
return render(request, "myapp/login_error.html")
# ...
login_required
¶login_required
(redirect_field_name='next', login_url=None)¶Sebagai jalan pintas, anda dapat menggunakan penghias login_required()
yang cocok.
from django.contrib.auth.decorators import login_required
@login_required
def my_view(request):
...
login_required()
melakukan berikut:
settings.LOGIN_URL
, melewati jalur mutlak saat ini di permintaan deretan karakter. Contoh: /accounts/login/?next=/polls/3/
.Secara awalan, jalur yang pengguna harus dialihkan untuk atas keberhasilan otentifikasi adalah disimpan di permintaan parameter deretan karakter disebut "next"
. Jika anda akan memilih menggunakan nama berbeda untuk parameter ini, login_required()
mengambil sebuah pilihan parameter redirect_field_name
.
from django.contrib.auth.decorators import login_required
@login_required(redirect_field_name="my_redirect_field")
def my_view(request):
...
Catat bahwa jika anda menyediakan nilai pada redirect_field_name
, anda akan paling disukai butuh menyesuaikan cetakan masuk anda juga, sejak cetakan varaibel konteks yang menyimpan jalur pengalihan akan menggunakan nilai dari redirect_field_name``sebagai kuncinya daripada ``"next"
(awalan).
login_required()
juga mengambil sebuah pilihan parameter login_url
. Contoh:
from django.contrib.auth.decorators import login_required
@login_required(login_url="/accounts/login/")
def my_view(request):
...
Catat bahwa jika anda tidak menentukan parameter login_url
, anda akan butuh memastikan bahwa settings.LOGIN_URL
dan tampilan masuk anda benar terhubung. Sebagai contoh, menggunakan awalan, tambah baris berikut ke URLconf anda:
from django.contrib.auth import views as auth_views
path("accounts/login/", auth_views.LoginView.as_view()),
settings.LOGIN_URL
juga menerima nama-nama fungsi tampilan dan named URL patterns. Ini mengizinkan anda secara bebas memetakan kembali ke tampilan masuk anda dalam URLconf tanpa harus memperbaharui pengaturan.
Catatan
Penghias login_required
TIDAK memeriksa bendera is_active
pada pengguna, tetapi awalan AUTHENTICATION_BACKENDS
menolak pengguna tidak aktif.
Lihat juga
Jika anda sedang menulis tampilan penyesuaian untuk Django admin (atau butuh pemeriksaan otorisasi sama bahwa tampilan pasang-tetap digunakan), anda mungkin menemukan penghias django.contrib.admin.views.decorators.staff_member_required()
cara lain yang berguna pada login_required()
.
LoginRequiredMixin
¶Ketika menggunakan class-based views, anda dapat mencapai kebiasaan lama seperti dengan login_required
dengan menggunakan LoginRequiredMixin
. Mixin harus di tempat paling kanan di daftar warisan.
LoginRequiredMixin
¶Jika sebuah tampilan menggunakan mixin ini, semua permintaan oleh pengguna bukan-terotentifikasi akan dialihkan ke halaman masuk atau menampilkan kesalahan HTTP 403 Forbidden, tergantung pada parameter raise_exception
.
Anda dapat menyetel tiap dari parameter dari AccessMixin
untuk menyesuaikan menangani dari pengguna tidak sah:
from django.contrib.auth.mixins import LoginRequiredMixin
class MyView(LoginRequiredMixin, View):
login_url = "/login/"
redirect_field_name = "redirect_to"
Catatan
Seperti penghias login_required
mixin ini TIDAK memeriksa bendera is_active
pada pengguna, tetapi awalan AUTHENTICATION_BACKENDS
menolak pengguna tidak aktif.
Untuk membatasi akses berdasarkan pada perizinan tertentu atau beberapa percobaan lain, anda akan melakukan pada dasarnya hal sama seperti digambarkan di bagian sebelumnya.
Anda dapat menjalankan pengujian anda pada request.user
di tampilan secara langsung. Misalnya, tampilan ini memeriksa untuk memastikan pengguna memiliki surel di domain yang diinginkan dan jika tidak, dialihkan ke halaman login
from django.shortcuts import redirect
def my_view(request):
if not request.user.email.endswith("@example.com"):
return redirect("/login/?next=%s" % request.path)
# ...
user_passes_test
(test_func, login_url=None, redirect_field_name='next')¶Sebagai sebuah jalan pintas, anda dapat menggunakan penghias user_passes_test
yang cocok yang melakukan sebuah pengalihan ketika callable mengembalikan False
:
from django.contrib.auth.decorators import user_passes_test
def email_check(user):
return user.email.endswith("@example.com")
@user_passes_test(email_check)
def my_view(request):
...
user_passes_test()
mengambil argumen wajib: sebuah callable yang mengambil obyek User
dan mengembalikan True
jika pengguna diizinkan melihat halaman. Catat bahwa user_passes_test()
tidak secara otomatis memeriksa bahwa the User
bukan anonim.
user_passes_test()
mengambil dua argumen pilihan:
login_url
settings.LOGIN_URL
jika anda tidak menentukan satu.redirect_field_name
login_required()
. Atur itu ke None
memindahkannya dari URL, yang anda mungkin ingin melakukannya jika anda mengalihkan pengguna yang tidak melewati percobaan ke halaman bukan-masuk dimana tidak ada "next page".Sebagai contoh:
@user_passes_test(email_check, login_url="/login/")
def my_view(request):
...
UserPassesTestMixin
¶Ketika menggunakan class-based views, anda dapat menggunakan UserPassesTestMixin
untuk melakukan ini.
test_func
()¶Anda harus menimpa metode test_func()
dari kelas untuk menyediakan percobaan yang dilakukan. Lebih lanjut, anda dapat menyetel tiap parameter dari AccessMixin
untuk menyesuaikan penangangan dari pengguna tidak sah:
from django.contrib.auth.mixins import UserPassesTestMixin
class MyView(UserPassesTestMixin, View):
def test_func(self):
return self.request.user.email.endswith("@example.com")
get_test_func
()¶Anda dapat juga menimpa metode get_test_func()
untuk memiliki penggunaan mixin fungsi bernama berbeda untuk pemeriksaannya (sebagai ganti test_func()
).
Menumpuk UserPassesTestMixin
Diakrenakan cara UserPassesTestMixin
diterapkan, anda tida dapat menumpuk mereka di daftar warisan anda. Berikut TIDAK bekerja:
class TestMixin1(UserPassesTestMixin):
def test_func(self):
return self.request.user.email.endswith("@example.com")
class TestMixin2(UserPassesTestMixin):
def test_func(self):
return self.request.user.username.startswith("django")
class MyView(TestMixin1, TestMixin2, View):
...
Jika TestMixin1
akan memanggil super()
dan mengambil hasi itu kedalam akun, TestMixin1
tidak akan bekerja berdiri sendiri lagi.
permission_required
¶permission_required
(perm, login_url=None, raise_exception=False)¶Itu adalah cara lain tugas umum untuk memeriksa apakah seorang pengguna mempunyai perizinan khusus. Untuk alasan tersebut, Django menyediakan jalan pintas untuk kasus itu: penghias the permission_required()
.:
from django.contrib.auth.decorators import permission_required
@permission_required("polls.add_choice")
def my_view(request):
...
Sama seperti metode has_perm()
, nama izin mengambil bentuk "<app label>.<permission codename>"
(yaitu polls.add_choice
untuk izin pada model di aplikasi polls
).
Penghias mungkin juga mengambil perizinan berulang, dalam hal ini pengguna harus memiliki semua perizinan untuk mengakses tampilan.
Catat bahwa permission_required()
juga mengambil sebuah pilihan parameter login_url
:
from django.contrib.auth.decorators import permission_required
@permission_required("polls.add_choice", login_url="/loginpage/")
def my_view(request):
...
Ketika di penghias login_required()
, awalan login_url
ke settings.LOGIN_URL
.
Jika parameter raise_exception
diberikan, penghias akan memunculkan PermissionDenied
, mendorong the 403 (HTTP Forbidden) view daripada mengalihkan ke halaman masuk.
Jika anda ingin menggunakan raise_exception
tetapi juga memberikan pengguna anda kesempatan untuk masuk terlebih dahulu, anda dapat menambahkan penghias login_required()
:
from django.contrib.auth.decorators import login_required, permission_required
@login_required
@permission_required("polls.add_choice", raise_exception=True)
def my_view(request):
...
Ini juga menghindari peralihan pengulangan ketika LoginView
redirect_authenticated_user=True
dan pengguna yang masuk tidak memiliki semua izin yang diperlukan.
PermissionRequiredMixin
¶Untuk memberlakukan pemeriksaan perizinan pada class-based views, anda dapat menggunakan PermissionRequiredMixin
:
PermissionRequiredMixin
¶Mixin ini, seperti penghias permission_required
, memeriksa apakah pengguna mengakses sebuah tampilan mempunyai semua perizinan yang diberikan. Anda harus menentukan perizinan (atau perulangan dari perizinan) menggunakan parameter permission_required
:
from django.contrib.auth.mixins import PermissionRequiredMixin
class MyView(PermissionRequiredMixin, View):
permission_required = "polls.add_choice"
# Or multiple of permissions:
permission_required = ["polls.view_choice", "polls.change_choice"]
Anda dapat menyetel tiap dari parameter dari AccessMixin
untuk menyesuaikan menangani dari pengguna tidak sah.
Anda dapat juga menimpa metode ini:
get_permission_required
()¶Mengembalikan perulangan dari nama perizinan digunakan oleh mixin. Awalan pada atribut permission_required
, dirubah ke sebuah tuple juka memungkinkan.
has_permission
()¶Mengembalikan sebuah boolean menunjukkan apakah pengguna saat ini mempunyai perizinan untuk menjalankan tampilan dihiasi. Secara awalan, ini mengembalikan hasil dari memanggil has_perms()
dengan daftar perizinan dikembalikan oleh get_permission_required()
.
Untuk memudahkan penanganan pembatasan akses di class-based views, AccessMixin
dapat digunakan untuk mengonfigurasi perilaku tampilan saat akses ditolak. Pengguna yang diautentikasi ditolak aksesnya dengan respons Terlarang HTTP 403. Pengguna anonim dialihkan ke halaman login atau ditampilkan respons Terlarang HTTP 403, tergantung pada atribut raise_exception
.
AccessMixin
¶login_url
¶Nilai balik awalan untuk get_login_url()
. Awalan pada None
dalam hal ini get_login_url()
jatuh kebelakang untuk settings.LOGIN_URL
.
permission_denied_message
¶Nilai balik awalan untuk get_permission_denied_message()
. Awalan pada sebuah deretan karakter kosong.
redirect_field_name
¶Nilai balikan awalan untuk get_redirect_field_name()
. Awalan ke "next"
.
raise_exception
¶Jika atribut ini disetel ke True
, pengecualian PermissionDenied
dimunculkan ketika kondisi tidak terpenuhi. Saat False
(default), pengguna anonim dialihkan ke halaman login.
get_login_url
()¶Mengembalikan URL yang pengguna tidak melewati percobaan akan dialihkan. Mengembalikan login_url
jika disetel, atau sebaliknya settings.LOGIN_URL
.
get_permission_denied_message
()¶Ketika raise_exception
adalah True
, metode ini dapat digunakan untuk mengendalikan pesan kesalahan dilewatkan ke penangan kesalahan untuk menampilkan ke pengguna. Mengembalikan atribut permission_denied_message
secara awalan.
get_redirect_field_name
()¶Mengembalikan nama dari permintaan parameter yang akan mengandung URL pengguna harus dialihkan setelah berhasil masuk. Jika anda menyetel ini ke None
, sebuah permintaan parameter tidak akan ditambahkan. Mengembalikan atribut redirect_field_name
secara awalan.
handle_no_permission
()¶Tergantung pada nilai dari raise_exception
, metode antara memunculkan pengecualian PermissionDenied
atau mengalihkan pengguna ke login_url
, secara pilihan menyertakan redirect_field_name
jika itu disetel.
Jika AUTH_USER_MODEL
anda warisan dari AbstractBaseUser
atau menerapkan metode get_session_auth_hash()
miliknya, sesi terotentifikasi akan menyertakan campuran dikembalikan oleh fungsi ini. Di kasus AbstractBaseUser
, ini adalah HMAC dari bidang sandi. Django memeriksa bahwa campuran di sesi untuk setiap permintaan cocok satu yang dihitung selama permintaan. Ini mengizinkan pengguna untuk keluar dari sesi mereka dengan merubah sandi mereka.
Tampilan rubah sandi awalan disertakan dengan Django, tampilan PasswordChangeView
dan the user_change_password
dalam admin django.contrib.auth
, perbaharui sesi dengan campuran sandi baru sehingga pengguna merubah sandi mereka sendiri tidak keluar. Jika anda mempunyai tampilan rubah sandi penyesuaian dan berharap memiliki perilaku sama, gunakan fungsi update_session_auth_hash()
.
update_session_auth_hash
(request, user)¶Fungsi ini mengambil permintaan saat ini dan memperbaharui obyek user dari dimana campuran sesi baru akan berasal dan memperbaharui campuran sesi dengan benar. Itu juga memutar kunci sesi sehingga kue sesi tercuri akan menjadi tidak sah.
Contoh penggunaan:
from django.contrib.auth import update_session_auth_hash
def password_change(request):
if request.method == "POST":
form = PasswordChangeForm(user=request.user, data=request.POST)
if form.is_valid():
form.save()
update_session_auth_hash(request, form.user)
else:
...
Catatan
Karena get_session_auth_hash()
didasarkan pada SECRET_KEY
, nilai kunci rahasia harus diputar untuk menghindari pembatalan sesi yang ada saat memperbarui situs anda untuk menggunakan rahasia baru . Lihat SECRET_KEY_FALLBACKS
untuk rinciannya.
Django menyediakan beberapa tampilan yang anda dapat gunakan untuk menangani masuk, keluarm dan pengelolaan sandi. Ini menggunakan dari stock auth forms tetapi anda dapat melewatkan nya ke dalam formulir anda sendiri juga.
Django menyediakan tidak ada awalan cetakan untuk tampilan otentifikasi. Anda harus membuat cetakan anda sendiri untuk tampilan anda ingin gunakan. Konteks cetakan adalah terdokumentasi di setiap tampilan, lihat Semua tempilan otentifikasi.
Ada perbedaan metode untuk menerapkan tampilan ini di proyek anda. Cara termudah adalah menyertakan URLconf yang disediakan di django.contrib.auth.urls
dalam URLConf anda sendiri, sebagai contoh:
urlpatterns = [
path("accounts/", include("django.contrib.auth.urls")),
]
Ini akan mencakup pola URL berikut:
accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']
Tampilan menyediakan nama URL untuk acuan lebih mudah. Lihat the URL documentation untuk rincian pada menggunakan corak URL bernama.
Jika anda ingin kendali lebih terhadap URL anda, anda dapat mengacu tampilan khusus di URLconf:
from django.contrib.auth import views as auth_views
urlpatterns = [
path("change-password/", auth_views.PasswordChangeView.as_view()),
]
Tampilan mempunyai argumen pilihan anda dapat gunakan untuk merubah kebiasaan dari tampilan. Sebagai contoh, jika anda ingin merubah nama cetakan tampilan kegunaan, anda dapat menyediakan argumen template_name
. Sebuah cara untuk melakukan ini adalah menyediakan argumen kata kunci dalam URLconf, ini akan dilewatkan ke tampilan. Sebagai contoh:
urlpatterns = [
path(
"change-password/",
auth_views.PasswordChangeView.as_view(template_name="change-password.html"),
),
]
Semua tampilan adalah class-based, yang mengizinkan anda dengan mudah menyesuaikan mereka dengan mensubkelaskan.
Ini adalah daftar dengan semua tamilan django.contrib.auth
sediakan. Untuk penerapan rincian lihat Menggunakan tamplian.
LoginView
¶Nama URL: masuk
Lihat the URL documentation untuk rincian pada menggunakan corak URL bernama.
Cara dan Atribut
template_name
¶Nama cetakan yang akan ditampilkan untuk tampilan yang digunakan untuk login pengguna. Awalannya adalah registration/login.html
.
next_page
¶URL tujuan pengalihan setelah login. Awalan ke LOGIN_REDIRECT_URL
.
redirect_field_name
¶Nama bidang GET
berisi URL tujuan pengalihan setelah login. Awalan ke berikutnya
. Mengganti URL get_default_redirect_url()
jika parameter GET
yang diberikan diteruskan.
authentication_form
¶Callable (biasanya kelas formulir) yang digunakan untuk autentikasi. Bawaan ke AuthenticationForm
.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
redirect_authenticated_user
¶Boolean yang mengontrol apakah pengguna terotentikasi mengakses halaman login atau tidak akan dialihkan seolah-olah mereka baru saja berhasil login. Awalan ke False
.
Peringatan
Jika anda mengadakan redirect_authenticated_user
, jaringan situs lainnya akan dapat menentukan jika pengunjung mereka adalah terotentifikasi pada situs anda dengan meminta pengalihan URL ke berkas gambar pada situs jaringan anda. Untuk menghindari ini "social media fingerprinting" kebocoran informasi, simpan semua gambar dan favicon anda pada ranah terpisah.
Mengaktifkan redirect_authenticated_user
juga dapat mengakibatkan pengalihan perulangan saat menggunakan dekorator permission_required()
kecuali parameter raise_exception
digunakan.
success_url_allowed_hosts
¶Sebuah set
dari host, selain request.get_host()
, yang aman untuk dialihkan setelah login. Awalan ke set
kosong.
get_default_redirect_url
()¶Mengembalikan URL tujuan pengalihan setelah masuk. Penerapan awalan menyelesaikan dan mengembalikan next_page
jika disetel, atau sebaliknya LOGIN_REDIRECT_URL
.
Ini adalah apa LoginView
lakukan:
GET
, itu menampilkan formulir masuk yang POST ke URL sama.Lebih dari ini dalam bit.POST
dengan pengguna mengajukan surat kepercayaan, itu mencoba untuk masuk pengguna. Jika masuk berhasil, tampilan mengalihkan ke URL ditentukan di next
tidak menyediakan, itu mengalihkan ke settings.LOGIN_REDIRECT_URL
(yang awalan menjadi /accounts/profile/
). Jika masuk tidak berhasil, itu menampilkan kembali formulir masuk.Itu adalah tanggung jawab anda untuk menyediakan html untuk cetakan masuk, dipanggil registration/login.html
secara awalan. Cetakan ini dilewatkan empat cetakan variabel konteks:
form
: Sebuah obyek Form
mewakili AuthenticationForm
.next
: URL untuk dialihkan setelah berhasil masuk. Ini mungkin mengandung permintaan string, juga.site
: Site`saat ini, menurut pengaturan :setting:`SITE_ID
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke sebuah instance dari RequestSite
, yang memperoleh nama situs dan ranah dari HttpRequest
saat ini.site_name
: Sebuah nama lain untuk site.name
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke nilai dari request.META['SERVER_NAME']
. Untuk lebih di situs, lihat Kerangka kerja "sites".Jika anda memilih tidak memanggil cetakan registration/login.html
, anda dapat melewatkan parameter template_name
melalui argumen tambahan pada metode as_view
dalam URLConf anda. Sebagai contoh, baris URLconf ini akan menggunakan myapp/login.html
sebagai gantinya.
path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),
Anda dapat juga menentukan nama dari bidang GET
yang mengandung URL untuk mengalihkan setelah masuk menggunakan redirect_field_name
. Secara awalan, bidang dipanggil next
.
Ini adalah sebuah contoh cetakan registration/login.html
anda dapat gunakan sebagai titik awalan. Itu menganggap anda memiliki sebuah cetakan base.html
yang menentukan sebuah blok content
.
{% extends "base.html" %}
{% block content %}
{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}
{% if next %}
{% if user.is_authenticated %}
<p>Your account doesn't have access to this page. To proceed,
please login with an account that has access.</p>
{% else %}
<p>Please login to see this page.</p>
{% endif %}
{% endif %}
<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
<td>{{ form.username.label_tag }}</td>
<td>{{ form.username }}</td>
</tr>
<tr>
<td>{{ form.password.label_tag }}</td>
<td>{{ form.password }}</td>
</tr>
</table>
<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>
{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>
{% endblock %}
Jika anda telah menyesuaiakan autentifikasi (lihat Customizing Authentication 1) anda dapat menggunakan formulir autentifikasi penyesuaian dengan mengatur atribut authentication_form
. Formulir ini harus menerima sebuah argumen katakunci request
dalam metode __init__()
nya dan menyediakan metode get_user()
yang mengembalikan obyek pengguna terautentifikasi (metode ini hanya dipanggil setelah keberhasilan formulir pengesahan).
LogoutView
¶Membuat pengguna keluar dari permintaan POST
.
Ditinggalkan sejak versi 4.1: Dukungan untuk keluar pada permintaan GET
tidak digunakan lagi dan akan dihapus di Django 5.0.
Nama URL: logout
Atribut
next_page
¶URL tujuan pengalihan setelah keluar. Awalan ke LOGOUT_REDIRECT_URL
.
template_name
¶Nama lengkap cetakan yang akan ditampilkan setelah pengguna keluar. Awalannya adalah registration/logged_out.html
.
redirect_field_name
¶Nama bidang GET
berisi URL tujuan pengalihan setelah keluar. Awalan ke 'berikutnya'
. Mengganti URL next_page
jika parameter GET
yang diberikan diteruskan.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
success_url_allowed_hosts
¶Sebuah set
dari host, selain request.get_host()
, yang aman untuk dialihkan setelah keluar. Awalan ke set
kosong.
Kontek cetakan
title
: String "Logged out", lokalisasi.site
: Site`saat ini, menurut pengaturan :setting:`SITE_ID
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke sebuah instance dari RequestSite
, yang memperoleh nama situs dan ranah dari HttpRequest
saat ini.site_name
: Sebuah nama lain untuk site.name
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke nilai dari request.META['SERVER_NAME']
. Untuk lebih di situs, lihat Kerangka kerja "sites".logout_then_login
(request, login_url=None)¶Keluarkan pengguna pada permintaan POST
, lalu alihkan ke halaman login.
Nama URL: Tidak ada URL awal disediakan
Argumen pilihan
login_url
: URL dari halaman masuk untuk mengalihkan. Awalan menjadi settings.LOGIN_URL
jika tidak diberikan.Ditinggalkan sejak versi 4.1: Dukungan untuk keluar pada permintaan GET
tidak digunakan lagi dan akan dihapus di Django 5.0.
PasswordChangeView
¶Nama URL: password_change
Izinkan pengguna merubah sandi mereka.
Atribut
template_name
¶Nama lengkap cetakan yang akan digunakan untuk menampilkan formulir perubahan kata sandi. Awalan ke registration/password_change_form.html
jika tidak disediakan.
success_url
¶URL tujuan pengalihan setelah perubahan sandi berhasil. Awalan ke 'password_change_done'
.
form_class
¶Formulir penyesuaian "ubah kata sandi" yang harus menerima argumen kata kunci user
. Formulir tersebut bertanggung jawab untuk benar-benar mengubah kata sandi pengguna. Awalan ke PasswordChangeForm
.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
Kontek cetakan
form
: Formulir rubah sandi (lihat form_class
diatas).PasswordChangeDoneView
¶Nama URL: password_change_done
Halaman muncul setelah pengguna telah merubah sandi mereka.
Atribut
template_name
¶Nama lengkap cetakan yang akan digunakan. Awalan ke registration/password_change_done.html
jika tidak disediakan.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
PasswordResetView
¶Nama URL: password_reset
Mengizinkan seorang pengguna menyetel kembali sandi dengan membangkitkan satu-kali penggunaan tautan yang dapat digunakan untuk menyetel kembali sandi, dan mengirim tautan itu ke alamat surel pengguna terdaftar.
Tampilan ini akan mengirim surel jika kondisi berikut terpenuhi:
User.is_active
adalah True
).set_unusable_password()
) tidak diizinkan untuk meminta penyetelan ulang kata sandi untuk mencegah penyalahgunaan saat menggunakan sumber autentikasi eksternal seperti LDAP.Jika salah satu dari ketentuan ini tidak terpenuhi, tidak ada surel yang akan dikirim, tetapi pengguna juga tidak akan menerima pesan kesalahan apa pun. Ini mencegah informasi bocor ke penyerang potensial. Jika anda ingin memberikan pesan kesalahan dalam kasus ini, Anda dapat membuat subkelas PasswordResetForm
dan menggunakan atribut form_class
.
Catatan
Ketahuilah bahwa mengirim surel membutuhkan waktu tambahan, karena itu anda mungkin rentan terhadap serangan waktu pencacahan alamat surel karena perbedaan antara durasi permintaan setel kembali untuk alamat surel yang ada dan durasi permintaan setel kembali untuk alamat surel yang tidak ada . Untuk mengurangi biaya diluar, Anda dapat menggunakan paket pihak ke-3 yang memungkinkan pengiriman surel secara asinkron, mis. django-mailer.
Atribut
template_name
¶Nama lengkap cetakan yang akan digunakan untuk menampilkan formulir pengaturan ulang kata sandi. Awalan ke registration/password_reset_form.html
jika tidak disediakan.
form_class
¶Formulir yang akan digunakan untuk mendapatkan surel pengguna untuk mensetel kembali kata sandi. Awalan ke PasswordResetForm
.
email_template_name
¶Nama lengkap cetakan yang akan digunakan untuk membuat surel dengan tautan atur ulang kata sandi. Awalan ke registration/password_reset_email.html
jika tidak disediakan.
subject_template_name
¶Nama lengkap cetakan yang akan digunakan untuk subjek surel dengan tautan atur ulang kata sandi. Awalan ke registration/password_reset_subject.txt
jika tidak disediakan.
token_generator
¶Instance dari kelas untuk memeriksa tautan satu kali. Ini akan awalan ke default_token_generator
, ini adalah instance dari django.contrib.auth.tokens.PasswordResetTokenGenerator
.
success_url
¶URL tujuan pengalihan setelah permintaan setel ulang sandi berhasil. Awalan ke 'password_reset_done'
.
from_email
¶Alamat surel yang sah. Secara awalan Django menggunakan DEFAULT_FROM_EMAIL
.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
html_email_template_name
¶Nama lengkap cetakan yang akan digunakan untuk membuat surel banyak bagian text/html dengan tautan setel ulang sandi. Secara awalan, email HTML tidak dikirim.
extra_email_context
¶Kamus data kontek yang akan tersedia di cetakan surel. Ini dapat digunakan untuk mengganti nilai konteks cetakan awalan yang tercantum di bawah ini, mis. domain
.
Kontek cetakan
form
: Formulir (lihat form_class
diatas) untuk mengatur kembali sandi pengguna.Konteks cetakan surel:
email
: Sebuah nama lain untuk user.email
user
: User
saat ini, menurut pada bidang formulir email
. Hanya pengguna aktif yang dapa menyetel kembali sandi mereka (User.is_active adalah True
).site_name
: Sebuah nama lain untuk site.name
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke nilai dari request.META['SERVER_NAME']
. Untuk lebih di situs, lihat Kerangka kerja "sites".domain
: Sebuah nama lain untuk site.domain
. Jika anda tidak mempunyai kerangka kerja situs terpasang, ini akan disetel ke nilai dari request.get_host()
.protocol
: http atau httpsuid
: Primary key pengguna disandikan dalam base 64.token
: Token untuk memeriksa bahwa tautan menyetel kembali adalah sah.Contoh registration/password_reset_email.html
(cetakan badan email):
Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
Konteks cetakan sama digunakan untuk cetakan subyek. Subyek harus berupa strng teks polosbaris tunggal.
PasswordResetDoneView
¶Nama URL: password_reset_done
Halaman muncul setelah pengguna telah disurelkan sebuah tautan untuk menyetel kembali sandi mereka. Tampilan ini dipanggil sebagai awalan jika PasswordResetView
tidak mempunyai kumpulan URL success_url
yang jelas.
Catatan
Jika alamat surel disediakan tidak ada di sistem, pengguna adalah tidak aktif, atau mempunyai sebuah sandi tidak berguna, pengguna akan masih dialihkan ke tampilan ini tetapi tidak ada surel yang akan dikirim.
Atribut
template_name
¶Nama lengkap cetakan yang akan digunakan. Awalan ke registration/password_reset_done.html
jika tidak disediakan.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
PasswordResetConfirmView
¶Nama URL: password_reset_confirm
Mengajukan sebuah formulir untuk memasukkan sebuah sandi baru.
Argumen katakunci dari URL:
uidb64
: id pengguna disandikan dalam base 64.token
: Token untuk memeriksa bahwa sandi adalah sah.Atribut
template_name
¶Nama lengkap cetakan untuk menampilkan tampilan konfirmasi kata sandi. Nilai awalannya adalah registration/password_reset_confirm.html
.
token_generator
¶Contoh kelas untuk memeriksa kata sandi. Ini akan awalan ke default_token_generator
, ini adalah instance dari django.contrib.auth.tokens.PasswordResetTokenGenerator
.
post_reset_login
¶Boolean yang menunjukkan apakah pengguna harus diautentikasi secara otomatis setelah setel ulang kata sandi berhasil. Awalan ke False
.
post_reset_login_backend
¶Jalur bertitik ke backend autentikasi untuk digunakan saat mengautentikasi pengguna jika post_reset_login
adalah True
. Diperlukan hanya jika anda memiliki beberapa konfigurasi AUTHENTICATION_BACKENDS
. Awalan ke Tidak Ada
.
form_class
¶Form yang akan digunakan untuk mengatur password. Awalan ke SetPasswordForm
.
success_url
¶URL untuk dialihkan setelah setel ulang kata sandi selesai. Awalan ke 'password_reset_complete'
.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
reset_url_token
¶Parameter token ditampilkan sebagai komponen URL setel ulang kata sandi. Awalan ke 'set-password'
.
Kontek cetakan
form
: Formulir (lihat form_class
above) untuk pengaturan san pengguna baru.validlink
: Boolean, True jika tautan (perpaduan dari uidb64
dan token
) adalah sah atau tidak digunakan.PasswordResetCompleteView
¶Nama URL: password_reset_complete
Menghadirkan sebuah tampilan yang menginformasikan pengguna bahwa sandi telah berhasil dirubah.
Atribut
template_name
¶Nama lengkap cetakan untuk menampilkan tampilan. Awalannya adalah registration/password_reset_complete.html
.
extra_context
¶Kamus data kontek yang akan ditambahkan ke data kontek awalan yang diteruskan ke cetakan.
redirect_to_login
(next, login_url=None, redirect_field_name='next')¶Dialihkan ke halaman masuk, dan kemudian kembali ke URL lain setelah berhasil masuk.
Argumen diwajibkan:
next
: URL untuk mengalihkan setelah berhasil masuk.Argumen pilihan
login_url
: URL dari halaman masuk untuk mengalihkan. Awalan menjadi settings.LOGIN_URL
jika tidak diberikan.redirect_field_name
: Nama dari bidang GET
mengandung URL untuk mengalihkan ke setelah keluar. Menimpa next
jika parameter GET
yang diberikan lolos.Jika anda tidak ingin menggunakan tampilan siap-pakai, tetapi ingin dengan meyakinkan tidak menulis formulir untuk kegunaan ini, sistem autentifikasi menyediakan beberapa formulir siap-pakai ditempatkan di django.contrib.auth.forms
:
Catatan
Formulir autentifikasi siap-pakai membuat pendapat tertentu tentang model user yang mereka bekerja dengannya. Jika anda sedang menggunakan sebuah custom user model, itu mungkin diperlukan menentukan formulir anda sendiri untuk sistem autentifikasi. Untuk informasi lebih, mengacu pada dokumentasi tentang using the built-in authentication forms with custom user models.
AdminPasswordChangeForm
¶Sebuah formulir digunakan di antarmuka admin untuk merubah sandi pengguna.
Mengambil argumen user
sebagai argumen penempatan pertama.
AuthenticationForm
¶Sebuah formulir untuk pengguna masuk.
Mengambil request
sebagai argumen penempatan pertama, yang disimpan pada instance formulir untuk digunakan oleh sub-kelas.
confirm_login_allowed
(user)¶Secara awalan, AuthenticationForm
menolak pengguna yang bendera is_active
disetel menjadi False
. Anda mungkin menimpa kebiasaan ini dengan kebijakan penyesuaian untuk menentukan pengguna mana dapat masuk. Lakukan ini dengan formulir penyesuaian yang mensubkelas AuthenticationForm
dan menimpa metode confirm_login_allowed()
. Metode ini harus memunculkan ValidationError
jika pengguna yang diberikan tidak masuk.
Sebagai contoh, untuk mengizinkan semua pengguna masuk tanpa memperhatikan keadaan "active":
from django.contrib.auth.forms import AuthenticationForm
class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
def confirm_login_allowed(self, user):
pass
(Dalam kasus ini, anda akan butuh menggunakan sebuah backend autentifikasi yang megnzinkan pengguna tidak aktif, seperti AllowAllUsersModelBackend
.)
Atau mengizinkan hanya beberapa pengguna aktif untuk masuk:
class PickyAuthenticationForm(AuthenticationForm):
def confirm_login_allowed(self, user):
if not user.is_active:
raise ValidationError(
_("This account is inactive."),
code="inactive",
)
if user.username.startswith("b"):
raise ValidationError(
_("Sorry, accounts starting with 'b' aren't welcome here."),
code="no_b_users",
)
PasswordChangeForm
¶Sebuah formulir untuk mengizinkan seorang pengguna merubah sandi mereka.
PasswordResetForm
¶Sebuah formulir untuk membangkitkan dan mensurelkan tautan penggunaan satu-kali untuk menyetel kembali sandi pengguna.
send_mail
(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)¶Menggunakan argumen untuk mengirimkan sebuah EmailMultiAlternatives
. Dapat ditimpa untuk menyesuaikan bagaimana surel dikirim ke pengguna.
Parameter: |
|
---|
Secara awalan, save()
mengumpulkan context
dengan variabel sama yang PasswordResetView
melewatkan ke konteks surelnya.
SetPasswordForm
¶Formulir yang membiarkan pengguma merubah sandi mereka tanpa memasukkan sandi lama.
UserChangeForm
¶Sebuah formulir digunakan di antarmuka admin untuk merubah infromasi dan perizinan pengguna.
BaseUserCreationForm
¶Sebuah ModelForm
untuk membuat pengguna baru. Ini adalah kelas dasar yang disarankan jika anda perlu menyesuaikan formulir pembuatan pengguna.
Itu mempunyai tiga bidang: username
(dari model user), password1
, dan password2
. Itu memeriksa bahwa password1
dan password2
cocok, mensahkan sandi menggunakan validate_password()
, dan menyetel sandi pengguna menggunakan set_password()
.
UserCreationForm
¶Mewarisi dari BaseUserCreationForm
. Untuk membantu mencegah kebingungan dengan nama pengguna yang mirip, formulir tidak mengizinkan nama pengguna yang berbeda hanya untuk berjaga-jaga.
Di versi yang lebih lama, UserCreationForm
tidak menyimpan kolom formulir many-to-many untuk model penyesuaian pengguna.
Di versi yang lebih lama, nama pengguna yang berbeda hanya diperbolehkan.
Pengguna masuk saat ini dan perizinan mereka dibuat tersedia di template context ketika anda menggunakan RequestContext
.
Secara teknis
Secara teknis, variabel-variabel ini hanya dibuat tersedia di konteks cetakan jika anda menggunakan pengolah konteks RequestContext
dan 'django.contrib.auth.context_processors.auth'
adalah diadakan. Itu berada di berkas pengaturan dibangkitkan awalan. Untuk lebih, lihat RequestContext docs.
Ketika membangun sebuah cetakan RequestContext
, pengguna masuk saat ini, antara instance User
atau instance AnonymousUser
, disimpan di variabel cetakan {{ user }}
:
{% if user.is_authenticated %}
<p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
<p>Welcome, new user. Please log in.</p>
{% endif %}
Variabel konteks cetakan ini tidak tersedia jika sebuah RequestContext
tidak sedang digunakan.
Perizinan pengguna masuk saat ini disimpan di variabel cetakan {{ perms }}
. Ini adalah sebuah instance dari django.contrib.auth.context_processors.PermWrapper
, yaitu sebuah proxy cetakan-ramah dari perizinan.
Mengevaluasi pencarian atribut tunggal dari {{ perms }}
sebagai boolean adalah proksi untuk User.has_module_perms()
. Misalnya, untuk memeriksa apakah pengguna yang masuk memiliki izin di aplikasi foo
:
{% if perms.foo %}
Mengevaluasi pencarian atribut dua-tingkat sebagai boolean adalah proksi ke User.has_perm()
. Misalnya, untuk memeriksa apakah pengguna yang masuk memiliki izin foo.add_vote
:
{% if perms.foo.add_vote %}
Ini adalah beberapa contoh lengkap dari perizinan pemeriksaan dalam sebuah cetakan:
{% if perms.foo %}
<p>You have permission to do something in the foo app.</p>
{% if perms.foo.add_vote %}
<p>You can vote!</p>
{% endif %}
{% if perms.foo.add_driving %}
<p>You can drive!</p>
{% endif %}
{% else %}
<p>You don't have permission to do anything in the foo app.</p>
{% endif %}
Itu memungkinkan juga mencari perizinan dengan pernyataan {% if in %}
. Sebagai contoh:
{% if 'foo' in perms %}
{% if 'foo.add_vote' in perms %}
<p>In lookup works, too.</p>
{% endif %}
{% endif %}
Ketika anda mempunyai kedua django.contrib.admin
dan django.contrib.auth
terpasang, admin menyediakan cara yang nyaman untuk menampilkan dan mengelola pengguna, kelompok, dan perizinan. Pengguna dapat dibuat dan dihapus seperti model Django apapun. Kelompok dapat dibuat, dan perizinan dapat diberikan ke pengguna atau kelompok. Sebuah catatan dari pengguna menyunting model dibuat dalam admin juga disimpan dan ditampilkan.
Anda harus melihat sebuah tautan pada "Users" di bagian "Auth" dari halaman indeks admin utama. Halaman admin "Add user" adalah berbeda dari halaman admin standar karena itu membutuhkan anda memilis sebuah nama pengguna dan sandi sebelum mengizinkan anda menyunting sisa dari bidang pengguna.
Juga catat: jika anda ingin seorang akun pengguna dapat membuat pengguna menggunakan situs admin Django, anda akan butuh memberikan mereka perizinan untuk menambahkan pengguna dan merubah pengguna (yaitu, perizinan "Add user" dan "Change user"). Jika sebuah akun mempunyai perizinan untuk menambah pengguna tetapi tidak merubah mereka, yang akun tidak dapat menambah pengguna. Kenapa, Karena jika anda mempunyai perizinan menambahkan pengguna, anda mempunyai kekuasaan membuat superuser, yang dapat kemudian, di gilirannya, rubah pengguna lain. Sehingga Django membuatuhkan tambah dan merubah perizinan sebagai ukuran keamanan sedikit.
Bijaksanalah tentang bagaimana anda mengizinkan pengguna mengelola perizinan. Jika anda memberikan bukan-superuser kemampuan menyunting pengguna, ini adalah akhirnya sama seperti memberikan mereka keadaan superuser karena mereka akan dapat memperbaiki perizinan dari pengguna menyertakan mereka sendiri!
Sandi pengguna tidak diperlihatkan di admin (maupun disimpan di basisdata), tetapi password storage details diperlihatkan. Disertakan di layar dari informasi ini adalah sebuah tautan pada sebuah formulir rubah sandi yang mengizinkan admin merubah sandi pengguna.
Des 04, 2023