---
title: "Menggunakan sistem pembuktian keaslian Django"
version: 4.1
locale: id
source: https://docs.djangoproject.com/id/4.1/topics/auth/default/
canonical: https://djangodocs.dev/id/4.1/topics/auth/default/
---
# Menggunakan sistem pembuktian keaslian Django

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](/id/4.1/topics/auth/customizing/) luas dari otentifikasi.

Otentifikasi Django menyediakan kedua otentifikasi dan otorisasi bersama-sama dan umumnya mengacu pada sebagai sistem otentifikasi, ketika fitur ini agak digabungkan.

## Obyek `User`

Obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.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'`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.is_superuser) atau admin pengguna [`'staff'`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.is_staff) hanya obyek user dengan sekumpulan atribut khusus, bukan kelas-kelas berbeda dari obyek user.

Atribut utama dari pengguna awal adalah:

- [`username`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.username)
- [`password`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.password)
- [`email`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.email)
- [`first_name`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.first_name)
- [`last_name`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.last_name)

Lihat :class:full API documentation \<django.contrib.auth.models.User\>\`untuk acuan penuh, dokumentasi yang mengikuti lebih berorientasi tugas.

### Membuat pengguna

Cara paling langsung untuk membuat pengguna adalah menggunakan fungsi pembantu [`create_user()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.UserManager.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](#auth-admin).

### Membuat pengguna hebat

Membuat pengguna hebat menggunakan perintah [`createsuperuser`](/id/4.1/ref/django-admin/#django-admin-createsuperuser):

```
$ python 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`](/id/4.1/ref/django-admin/#cmdoption-createsuperuser-username) atau [`--email`](/id/4.1/ref/django-admin/#cmdoption-createsuperuser-email), itu akan meminta anda untuk nilai-nilai tersebut.

### Merubah sandi

Django tidak menyimpan sandi (teks bersih) mentah pada model user, tetapi hanya campuran (lihat [documentation of how passwords are managed](/id/4.1/topics/auth/passwords/) 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*`](/id/4.1/ref/django-admin/#django-admin-changepassword) 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()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.set_password):

```pycon
>>> 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](#auth-admin).

Django juga menyediakan [views](#built-in-auth-views) dan [forms](#built-in-auth-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](#session-invalidation-on-password-change) untuk rincian.

### Pembuktian keaslian pengguna

#### `authenticate(request=None, **credentials)`

Gunakan [`authenticate()`](#django.contrib.auth.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](/id/4.1/topics/auth/customizing/#authentication-backends), dan kembalikan obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) jika mandat sah untuk backend. Jika mandat tidak sah untuk setiap backend atau jika backend menampilkan [`PermissionDenied`](/id/4.1/ref/exceptions/#django.core.exceptions.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`](/id/4.1/ref/request-response/#django.http.HttpRequest) yang dilewatkan pada metode `authenticate()` dari backend autentifikasi.

> **Note**
>
> Ini adalah cara tingkat bawah untuk mengautentifikasi kumpulan dari kepercayaan; sebagai contoh, itu digunakan oleh [`RemoteUserMiddleware`](/id/4.1/ref/middleware/#django.contrib.auth.middleware.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.contrib.auth.views.LoginView).

## Perizinan dan Pembuktian keaslian

Django comes with a built-in permissions system. It provides a way to assign
permissions to specific users and groups of users.

Digunakan oleh situs admin Django, tetapi anda dipersilahkan menggunakannya di kode anda sendiri.

Situs admin Django menggunakan perizinan sebagai berikut:

- Akses untuk menampilkan obyek adalah terbatas pada pengguna dengan perizinan "view" atau "change" untuk jenis itu dari obyek.
- Akses ke tampilan formulir "add" dan menambah sebuah obyek adalah terbatas untuk pengguna dengan perizinan "add" untuk jenis itu dari obyek.
- Akses ke tampilan daftar perubahan, tampilan formulir "change" dan merubah sebuah obyek adalah terbatas untuk pengguna dengan perizinan "change" untuk jenis obyek itu.
- Akses untuk menghapus sebuah obyek adalah terbatas pada pengguna dengan perizinan "hapus" untuk jenis itu dari obyek.

Permissions can be set not only per type of object, but also per specific
object instance. By using the
[`has_view_permission()`](/id/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_view_permission),
[`has_add_permission()`](/id/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_add_permission),
[`has_change_permission()`](/id/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_change_permission) and
[`has_delete_permission()`](/id/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission) methods provided
by the [`ModelAdmin`](/id/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin) class, it is possible to
customize permissions for different object instances of the same type.

Obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) mempunyai dua bidang many-to-many: `groups` dan `user_permissions`. Obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) dapat mengakses obyek terkait mereka di cara yang sama seperti yang [Django model](/id/4.1/topics/db/models/) 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()
```

### Perizinan pertama

When `django.contrib.auth` is listed in your [`INSTALLED_APPS`](/id/4.1/ref/settings/#std-setting-INSTALLED_APPS)
setting, it will ensure that four default permissions -- add, change, delete,
and view -- are created for each Django model defined in one of your installed
applications.

Perizinan ini akan dibuat ketika anda menjalankan [`manage.py migrate`](/id/4.1/ref/django-admin/#django-admin-migrate); pertama kali anda menjalankan `migrate` setelah menambahkan `django.contrib.auth` pada [`INSTALLED_APPS`](/id/4.1/ref/settings/#std-setting-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`](/id/4.1/ref/django-admin/#django-admin-migrate) (fungsi yang membuat perizinan adalah terhubung ke sinyal [`post_migrate`](/id/4.1/ref/signals/#django.db.models.signals.post_migrate)).

Menganggap anda memiliki sebuah aplikasi dengan [`app_label`](/id/4.1/ref/models/options/#django.db.models.Options.app_label) `foo` dan model bernama `Bar`, pada percobaan untuk perizinan dasar anda harus gunakan:

- tambah: `user.has_perm('foo.add_bar')`
- rubah: `user.has_perm('foo.change_bar')`
- hapus: `user.has_perm('foo.delete_bar')`
- view: `user.has_perm('foo.view_bar')`

Model [`Permission`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.Permission) jarang diakses secara langsung.

### Kelompok

Model [`django.contrib.auth.models.Group`](/id/4.1/ref/contrib/auth/#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.

### Pemrograman membuat perizinan

Selagi [custom permissions](/id/4.1/topics/auth/customizing/#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`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) melalui atribut `user_permissions` nya atau ke [`Group`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.Group) melalui atribut `permissions` nya.

> **Proxy models need their own content type**
>
> If you want to create [permissions for a proxy model](#proxy-models-permissions-topic), pass `for_concrete_model=False` to
> [`ContentTypeManager.get_for_model()`](/id/4.1/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentTypeManager.get_for_model) to get the appropriate
> `ContentType`:
>
> ```
> content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)
> ```

### Perizinan penyimpanan sementara

Perizinan tembolok [`ModelBackend`](/id/4.1/ref/contrib/auth/#django.contrib.auth.backends.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

Proxy models work exactly the same way as concrete models. Permissions are
created using the own content type of the proxy model. Proxy models don't
inherit the permissions of the concrete model they subclass:

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

## Authentication in web requests

Django menggunakan [sessions](/id/4.1/topics/http/sessions/) dan middleware untuk menghubungkan sitem otentifikasi kedalam [`request objects`](/id/4.1/ref/request-response/#django.http.HttpRequest).

Ini menyediakan sebuah atribut [`request.user`](/id/4.1/ref/request-response/#django.http.HttpRequest.user) pada setiap permintaan yang mewakili pengguna saat ini. Jika pengguna saat ini belum masuk, atribut ini akan disetel ke sebuah instance dari [`AnonymousUser`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser), sebaliknya itu akan berupa sebuah instance dari [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User).

Anda dapat memberitahu mereka selain dengan [`is_authenticated`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.is_authenticated), seperti begitu

```
if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...
```

### Bagaimana cara masuk pengguna

Jika anda mempunyai pengguna terotentifikasi anda ingin lampirkan ke sesi saat ini - ini dilakukan dengan fungsi [`login()`](#django.contrib.auth.login).

#### `login(request, user, backend=None)`

Untuk pengguna masuk, dari tampilan, gunakan [`login()`](#django.contrib.auth.login). Itu mengambil sebuah obyek [`HttpRequest`](/id/4.1/ref/request-response/#django.http.HttpRequest) dan sebuah obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User). [`login()`](#django.contrib.auth.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()`](#django.contrib.auth.authenticate) dan [`login()`](#django.contrib.auth.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.
        ...
```

#### Memilih backend otentifikasi

Ketika seorang pengguna masuk, ID pengguna dan backend yang telah digunakan untuk autentifikasi disimpan dalam sesi pengguna. Ini mengizinkan [authentication backend](/id/4.1/topics/auth/customizing/#authentication-backends) sama untuk mengambil rincian pengguna pada permintaan akan datang. Backend autentifikasi untuk menyimpan sesi dipilih sebagai berikut:

1. Gunakan nilai dai argumen `backend` pilihan, jika disediakan.
2. Gunakan nilai dari atribut `user.backend`, jika hadir. Ini mengizinkan memasangkan [`authenticate()`](#django.contrib.auth.authenticate) dan [`login()`](#django.contrib.auth.login): [`authenticate()`](#django.contrib.auth.authenticate) menyetel atribut  `user.backend` pada obyek user dia kembalikan.
3. Gunakan `backend` dalam [`AUTHENTICATION_BACKENDS`](/id/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), jika hanya ada satu.
4. Sebaliknya, munculkan sebuah pengecualian.

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`](/id/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS)), bukan kelas backend sebenarnya.

### Bagaimana cara pengguna keluar

#### `logout(request)`

Untuk keluar pengguna yang telah masuk melalui [`django.contrib.auth.login()`](#django.contrib.auth.login), gunakan [`django.contrib.auth.logout()`](#django.contrib.auth.logout) dalam tampilan anda. Itu mengambil sebuah obyek [`HttpRequest`](/id/4.1/ref/request-response/#django.http.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()`](#django.contrib.auth.logout) tidak melempar kesalahan apapun jika pengguna tidak masuk.

When you call [`logout()`](#django.contrib.auth.logout), the session data for
the current request is completely cleaned out. All existing data is
removed. This is to prevent another person from using the same web browser
to log in and have access to the previous user's session data. If you want
to put anything into the session that will be available to the user
immediately after logging out, do that *after* calling
[`django.contrib.auth.logout()`](#django.contrib.auth.logout).

### Membatasi akses ke pengguna masuk

#### Cara mentah

The raw way to limit access to pages is to check
[`request.user.is_authenticated`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.is_authenticated) and either redirect to a
login page:

```
from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, 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')
    # ...
```

#### Penghias `login_required`

#### `login_required(redirect_field_name='next', login_url=None)`

Sebagai jalan pintas, anda dapat menggunakan penghias [`login_required()`](#django.contrib.auth.decorators.login_required) yang cocok.

```
from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...
```

[`login_required()`](#django.contrib.auth.decorators.login_required) melakukan berikut:

- Jika pengguna tidak masuk, alihkan ke [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL), melewati jalur mutlak saat ini di permintaan deretan karakter. Contoh: `/accounts/login/?next=/polls/3/`.
- Jika pengguna masuk, jalankan tampilan secara biasa. Kode tampilan adalah bebas untuk menganggap pengguna adalah masuk.

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()`](#django.contrib.auth.decorators.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()`](#django.contrib.auth.decorators.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`](/id/4.1/ref/settings/#std-setting-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`](/id/4.1/ref/settings/#std-setting-LOGIN_URL) juga menerima nama-nama fungsi tampilan dan [named URL patterns](/id/4.1/topics/http/urls/#naming-url-patterns). Ini mengizinkan anda secara bebas memetakan kembali ke tampilan masuk anda dalam URLconf tanpa harus memperbaharui pengaturan.

> **Note**
>
> Penghias  `login_required` TIDAK memeriksa bendera `is_active` pada pengguna, tetapi awalan [`AUTHENTICATION_BACKENDS`](/id/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) menolak pengguna tidak aktif.

> **See also**
>
> 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()`](/id/4.1/ref/contrib/admin/#django.contrib.admin.views.decorators.staff_member_required) cara lain yang berguna pada `login_required()`.

#### The `LoginRequiredMixin` mixin

Ketika menggunakan [class-based views](/id/4.1/topics/class-based-views/), anda dapat mencapai kebiasaan lama seperti dengan `login_required` dengan menggunakan `LoginRequiredMixin`. Mixin harus di tempat paling kanan di daftar warisan.

#### `class 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`](#django.contrib.auth.mixins.AccessMixin.raise_exception).

Anda dapat menyetel tiap dari parameter dari [`AccessMixin`](#django.contrib.auth.mixins.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'
```

> **Note**
>
> Seperti penghias `login_required` mixin ini TIDAK memeriksa bendera `is_active` pada pengguna, tetapi awalan [`AUTHENTICATION_BACKENDS`](/id/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) menolak pengguna tidak aktif.

#### Membatasi akses ke pengguna masuk yang melewatkan percobaan

Untuk membatasi akses berdasarkan pada perizinan tertentu atau beberapa percobaan lain, anda akan melakukan pada dasarnya hal sama seperti digambarkan di bagian sebelumnya.

You can run your test on [`request.user`](/id/4.1/ref/request-response/#django.http.HttpRequest.user) in
the view directly. For example, this view checks to make sure the user has an
email in the desired domain and if not, redirects to the login page:

```
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()`](#django.contrib.auth.decorators.user_passes_test) mengambil argumen wajib: sebuah callable yang mengambil obyek [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) dan mengembalikan `True` jika pengguna diizinkan melihat halaman. Catat bahwa [`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) tidak secara otomatis memeriksa bahwa the [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) bukan anonim.

[`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) mengambil dua argumen pilihan:

**`login_url`**

  Biarkan anda menentukan URL yang pengguna tidak melewati percobaan akan dialihkan. Itu mungkin halaman masuk dan awalan ke [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL) jika anda tidak menentukan satu.

**`redirect_field_name`**

  Sama seperti [`login_required()`](#django.contrib.auth.decorators.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):
    ...
```

#### `class UserPassesTestMixin`

Ketika menggunakan [class-based views](/id/4.1/topics/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`](#django.contrib.auth.mixins.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()`](#django.contrib.auth.mixins.UserPassesTestMixin.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.

#### Penghias `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()`](#django.contrib.auth.decorators.permission_required).:

```
from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice')
def my_view(request):
    ...
```

Just like the [`has_perm()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perm) method,
permission names take the form `"<app label>.<permission codename>"`
(i.e. `polls.add_choice` for a permission on a model in the `polls`
application).

Penghias mungkin juga mengambil perizinan berulang, dalam hal ini pengguna harus memiliki semua perizinan untuk mengakses tampilan.

Catat bahwa [`permission_required()`](#django.contrib.auth.decorators.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()`](#django.contrib.auth.decorators.login_required), awalan `login_url`  ke [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL).

Jika parameter `raise_exception` diberikan, penghias akan memunculkan [`PermissionDenied`](/id/4.1/ref/exceptions/#django.core.exceptions.PermissionDenied), mendorong [the 403 (HTTP Forbidden) view](/id/4.1/ref/views/#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()`](#django.contrib.auth.decorators.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):
    ...
```

This also avoids a redirect loop when [`LoginView`](#django.contrib.auth.views.LoginView)'s
`redirect_authenticated_user=True` and the logged-in user doesn't have
all of the required permissions.

#### Mixin `PermissionRequiredMixin`

Untuk memberlakukan pemeriksaan perizinan pada [class-based views](/id/4.1/ref/class-based-views/), anda dapat menggunakan `PermissionRequiredMixin`:

#### `class 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`](#django.contrib.auth.mixins.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()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perms) dengan daftar perizinan dikembalikan oleh [`get_permission_required()`](#django.contrib.auth.mixins.PermissionRequiredMixin.get_permission_required).

### Mengalihkan permintaan tidak sah di tampilan berdasarkan-kelas

To ease the handling of access restrictions in [class-based views](/id/4.1/ref/class-based-views/), the `AccessMixin` can be used to configure
the behavior of a view when access is denied. Authenticated users are denied
access with an HTTP 403 Forbidden response. Anonymous users are redirected to
the login page or shown an HTTP 403 Forbidden response, depending on the
[`raise_exception`](#django.contrib.auth.mixins.AccessMixin.raise_exception) attribute.

#### `class AccessMixin`

#### `login_url`

Nilai balik awalan untuk [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url). Awalan pada `None` dalam hal ini [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url) jatuh kebelakang untuk [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL).

#### `permission_denied_message`

Nilai balik awalan untuk [`get_permission_denied_message()`](#django.contrib.auth.mixins.AccessMixin.get_permission_denied_message). Awalan pada sebuah deretan karakter kosong.

#### `redirect_field_name`

Nilai balikan awalan untuk [`get_redirect_field_name()`](#django.contrib.auth.mixins.AccessMixin.get_redirect_field_name). Awalan ke `"next"`.

#### `raise_exception`

If this attribute is set to `True`, a
[`PermissionDenied`](/id/4.1/ref/exceptions/#django.core.exceptions.PermissionDenied) exception is raised
when the conditions are not met.  When `False` (the default),
anonymous users are redirected to the login page.

#### `get_login_url()`

Mengembalikan URL yang pengguna tidak melewati percobaan akan dialihkan. Mengembalikan [`login_url`](#django.contrib.auth.mixins.AccessMixin.login_url) jika disetel, atau sebaliknya [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL).

#### `get_permission_denied_message()`

Ketika [`raise_exception`](#django.contrib.auth.mixins.AccessMixin.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`](#django.contrib.auth.mixins.AccessMixin.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`](#django.contrib.auth.mixins.AccessMixin.redirect_field_name) secara awalan.

#### `handle_no_permission()`

Tergantung pada nilai dari `raise_exception`, metode antara memunculkan pengecualian [`PermissionDenied`](/id/4.1/ref/exceptions/#django.core.exceptions.PermissionDenied) atau mengalihkan pengguna ke `login_url`, secara pilihan menyertakan `redirect_field_name` jika itu disetel.

#### Penghapusan sesi pada perubahan sandi

Jika [`AUTH_USER_MODEL`](/id/4.1/ref/settings/#std-setting-AUTH_USER_MODEL) anda warisan dari [`AbstractBaseUser`](/id/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser) atau menerapkan metode [`get_session_auth_hash()`](/id/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) miliknya, sesi terotentifikasi akan menyertakan campuran dikembalikan oleh fungsi ini. Di kasus [`AbstractBaseUser`](/id/4.1/topics/auth/customizing/#django.contrib.auth.models.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`](#django.contrib.auth.views.PasswordChangeView) dan the `user_change_password` dalam admin [`django.contrib.auth`](/id/4.1/topics/auth/#module-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()`](#django.contrib.auth.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:
        ...
```

> **Note**
>
> Since
> [`get_session_auth_hash()`](/id/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash)
> is based on [`SECRET_KEY`](/id/4.1/ref/settings/#std-setting-SECRET_KEY), secret key values must be
> rotated to avoid invalidating existing sessions when updating your site to
> use a new secret. See [`SECRET_KEY_FALLBACKS`](/id/4.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) for details.

### Tampilan Otentifikasi

Django menyediakan beberapa tampilan yang anda dapat gunakan untuk menangani masuk, keluarm dan pengelolaan sandi. Ini menggunakan dari [stock auth forms](#built-in-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](#all-authentication-views).

#### Menggunakan tamplian

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 menyertakan 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](/id/4.1/topics/http/urls/) 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](/id/4.1/topics/class-based-views/), yang mengizinkan anda dengan mudah menyesuaikan mereka dengan mensubkelaskan.

#### Semua tempilan otentifikasi

Ini adalah daftar dengan semua tamilan `django.contrib.auth` sediakan. Untuk penerapan rincian lihat [Menggunakan tamplian](#using-the-views).

#### `class LoginView`

**Nama URL:** `masuk`

Lihat [the URL documentation](/id/4.1/topics/http/urls/) untuk rincian pada menggunakan corak URL bernama.

**Cara dan Atribut**

#### `template_name`

The name of a template to display for the view used to log the user in.
Defaults to `registration/login.html`.

#### `next_page`

> **New in Django 4.0**

The URL to redirect to after login. Defaults to
[`LOGIN_REDIRECT_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_REDIRECT_URL).

#### `redirect_field_name`

The name of a `GET` field containing the URL to redirect to after
login. Defaults to `next`. Overrides the
[`get_default_redirect_url()`](#django.contrib.auth.views.LoginView.get_default_redirect_url) URL if the given `GET` parameter is
passed.

#### `authentication_form`

A callable (typically a form class) to use for authentication. Defaults
to [`AuthenticationForm`](#django.contrib.auth.forms.AuthenticationForm).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `redirect_authenticated_user`

A boolean that controls whether or not authenticated users accessing
the login page will be redirected as if they had just successfully
logged in. Defaults to `False`.

> **Warning**
>
> 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](https://robinlinus.github.io/socialmedia-leak/)" kebocoran informasi, simpan semua gambar dan favicon anda pada ranah terpisah.
>
> Enabling `redirect_authenticated_user` can also result in a
> redirect loop when using the [`permission_required()`](#django.contrib.auth.decorators.permission_required) decorator
> unless the `raise_exception` parameter is used.

#### `success_url_allowed_hosts`

A [`set`](https://docs.python.org/3/library/stdtypes.html#set) of hosts, in addition to [`request.get_host()`](/id/4.1/ref/request-response/#django.http.HttpRequest.get_host), that are safe for redirecting
after login. Defaults to an empty [`set`](https://docs.python.org/3/library/stdtypes.html#set).

#### `get_default_redirect_url()`

> **New in Django 4.0**

Returns the URL to redirect to after login. The default implementation
resolves and returns [`next_page`](#django.contrib.auth.views.LoginView.next_page) if set, or
[`LOGIN_REDIRECT_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_REDIRECT_URL) otherwise.

Ini adalah apa `LoginView` lakukan:

- Jika dipanggil melalui `GET`, itu menampilkan formulir masuk yang POST ke URL sama.Lebih dari ini dalam bit.
- Jika dipanggil melalui `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`](/id/4.1/ref/settings/#std-setting-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`](/id/4.1/ref/forms/api/#django.forms.Form) mewakili [`AuthenticationForm`](#django.contrib.auth.forms.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`](/id/4.1/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), yang memperoleh nama situs dan ranah dari [`HttpRequest`](/id/4.1/ref/request-response/#django.http.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']`](/id/4.1/ref/request-response/#django.http.HttpRequest.META). Untuk lebih di situs, lihat [Kerangka kerja "sites"](/id/4.1/ref/contrib/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`.

```html+django
{% 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).

#### `class LogoutView`

Logs a user out on `POST` requests.

> **Deprecated since Django 4.1**
>
> Ditinggalkan sejak versi 4.1: Support for logging out on `GET` requests is deprecated and will be
> removed in Django 5.0.

**Nama URL:** `logout`

**Atribut**

#### `next_page`

The URL to redirect to after logout. Defaults to
[`LOGOUT_REDIRECT_URL`](/id/4.1/ref/settings/#std-setting-LOGOUT_REDIRECT_URL).

#### `template_name`

The full name of a template to display after logging the user out.
Defaults to `registration/logged_out.html`.

#### `redirect_field_name`

The name of a `GET` field containing the URL to redirect to after log
out. Defaults to `'next'`. Overrides the
[`next_page`](#django.contrib.auth.views.LogoutView.next_page) URL if the given `GET` parameter is
passed.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `success_url_allowed_hosts`

A [`set`](https://docs.python.org/3/library/stdtypes.html#set) of hosts, in addition to [`request.get_host()`](/id/4.1/ref/request-response/#django.http.HttpRequest.get_host), that are safe for redirecting
after logout. Defaults to an empty [`set`](https://docs.python.org/3/library/stdtypes.html#set).

**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`](/id/4.1/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), yang memperoleh nama situs dan ranah dari [`HttpRequest`](/id/4.1/ref/request-response/#django.http.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']`](/id/4.1/ref/request-response/#django.http.HttpRequest.META). Untuk lebih di situs, lihat [Kerangka kerja "sites"](/id/4.1/ref/contrib/sites/).

#### `logout_then_login(request, login_url=None)`

Logs a user out on `POST` requests, then redirects to the login page.

**Nama URL:** Tidak ada URL awal disediakan

**Argumen pilihan**

- `login_url`: URL dari halaman masuk untuk mengalihkan. Awalan menjadi [`settings.LOGIN_URL`](/id/4.1/ref/settings/#std-setting-LOGIN_URL) jika tidak diberikan.

> **Deprecated since Django 4.1**
>
> Ditinggalkan sejak versi 4.1: Support for logging out on `GET` requests is deprecated and will be
> removed in Django 5.0.

#### `class PasswordChangeView`

**Nama URL:** `password_change`

Izinkan pengguna merubah sandi mereka.

**Atribut**

#### `template_name`

The full name of a template to use for displaying the password change
form. Defaults to `registration/password_change_form.html` if not
supplied.

#### `success_url`

The URL to redirect to after a successful password change. Defaults to
`'password_change_done'`.

#### `form_class`

A custom "change password" form which must accept a `user` keyword
argument. The form is responsible for actually changing the user's
password. Defaults to
[`PasswordChangeForm`](#django.contrib.auth.forms.PasswordChangeForm).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

**Kontek cetakan**

- `form`: Formulir rubah sandi (lihat `form_class` diatas).

#### `class PasswordChangeDoneView`

**Nama URL:** `password_change_done`

Halaman muncul setelah pengguna telah merubah sandi mereka.

**Atribut**

#### `template_name`

The full name of a template to use. Defaults to
`registration/password_change_done.html` if not supplied.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `class 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.

This view will send an email if the following conditions are met:

- The email address provided exists in the system.
- The requested user is active (`User.is_active` is `True`).
- The requested user has a usable password. Users flagged with an unusable
  password (see
  [`set_unusable_password()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.set_unusable_password)) aren't
  allowed to request a password reset to prevent misuse when using an
  external authentication source like LDAP.

If any of these conditions are *not* met, no email will be sent, but the
user won't receive any error message either. This prevents information
leaking to potential attackers. If you want to provide an error message in
this case, you can subclass
[`PasswordResetForm`](#django.contrib.auth.forms.PasswordResetForm) and use the
`form_class` attribute.

> **Note**
>
> Be aware that sending an email costs extra time, hence you may be
> vulnerable to an email address enumeration timing attack due to a
> difference between the duration of a reset request for an existing
> email address and the duration of a reset request for a nonexistent
> email address. To reduce the overhead, you can use a 3rd party package
> that allows to send emails asynchronously, e.g. [django-mailer](https://pypi.org/project/django-mailer/).

**Atribut**

#### `template_name`

The full name of a template to use for displaying the password reset
form. Defaults to `registration/password_reset_form.html` if not
supplied.

#### `form_class`

Form that will be used to get the email of the user to reset the
password for. Defaults to
[`PasswordResetForm`](#django.contrib.auth.forms.PasswordResetForm).

#### `email_template_name`

The full name of a template to use for generating the email with the
reset password link. Defaults to
`registration/password_reset_email.html` if not supplied.

#### `subject_template_name`

The full name of a template to use for the subject of the email with
the reset password link. Defaults to
`registration/password_reset_subject.txt` if not supplied.

#### `token_generator`

Instance of the class to check the one time link. This will default to
`default_token_generator`, it's an instance of
`django.contrib.auth.tokens.PasswordResetTokenGenerator`.

#### `success_url`

The URL to redirect to after a successful password reset request.
Defaults to `'password_reset_done'`.

#### `from_email`

A valid email address. By default Django uses the
[`DEFAULT_FROM_EMAIL`](/id/4.1/ref/settings/#std-setting-DEFAULT_FROM_EMAIL).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `html_email_template_name`

The full name of a template to use for generating a
`text/html` multipart email with the password reset link. By
default, HTML email is not sent.

#### `extra_email_context`

A dictionary of context data that will be available in the email
template. It can be used to override default template context values
listed below e.g. `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`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.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']`](/id/4.1/ref/request-response/#django.http.HttpRequest.META). Untuk lebih di situs, lihat [Kerangka kerja "sites"](/id/4.1/ref/contrib/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 https
- `uid`: 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):

```html+django
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.

#### `class 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`](#django.contrib.auth.views.PasswordResetView) tidak mempunyai kumpulan URL `success_url` yang jelas.

> **Note**
>
> 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`

The full name of a template to use. Defaults to
`registration/password_reset_done.html` if not supplied.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `class 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`

The full name of a template to display the confirm password view.
Default value is `registration/password_reset_confirm.html`.

#### `token_generator`

Instance of the class to check the password. This will default to
`default_token_generator`, it's an instance of
`django.contrib.auth.tokens.PasswordResetTokenGenerator`.

#### `post_reset_login`

A boolean indicating if the user should be automatically authenticated
after a successful password reset. Defaults to `False`.

#### `post_reset_login_backend`

A dotted path to the authentication backend to use when authenticating
a user if `post_reset_login` is `True`. Required only if you have
multiple [`AUTHENTICATION_BACKENDS`](/id/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) configured. Defaults to
`None`.

#### `form_class`

Form that will be used to set the password. Defaults to
[`SetPasswordForm`](#django.contrib.auth.forms.SetPasswordForm).

#### `success_url`

URL to redirect after the password reset done. Defaults to
`'password_reset_complete'`.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `reset_url_token`

Token parameter displayed as a component of password reset URLs.
Defaults to `'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.

#### `class PasswordResetCompleteView`

**Nama URL:** `password_reset_complete`

Menghadirkan sebuah tampilan yang menginformasikan pengguna bahwa sandi telah berhasil dirubah.

**Atribut**

#### `template_name`

The full name of a template to display the view. Defaults to
`registration/password_reset_complete.html`.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

### Fungsi pembantu

#### `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`](/id/4.1/ref/settings/#std-setting-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.

### Formulir siap pakai

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`](#module-django.contrib.auth.forms):

> **Note**
>
> Formulir autentifikasi siap-pakai membuat pendapat tertentu tentang model user yang mereka bekerja dengannya. Jika anda sedang menggunakan sebuah [custom user model](/id/4.1/topics/auth/customizing/#auth-custom-user), 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](/id/4.1/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms).

#### `class AdminPasswordChangeForm`

Sebuah formulir digunakan di antarmuka admin untuk merubah sandi pengguna.

Mengambil argumen `user` sebagai argumen penempatan pertama.

#### `class 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`](/id/4.1/ref/exceptions/#django.core.exceptions.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`](/id/4.1/ref/contrib/auth/#django.contrib.auth.backends.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',
            )
```

#### `class PasswordChangeForm`

Sebuah formulir untuk mengizinkan seorang pengguna merubah sandi mereka.

#### `class 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:** - `subject_template_name` -- cetakan untuk subyek.
- `email_template_name` -- cetakan untuk badan surel.
- `context` -- konteks dilewatkan ke `subject_template`, `email_template`, dan `html_email_template` (jika itu bukan `None`).
- `from_email` -- surel pengirim
- `to_email` -- surel dari peminta.
- `html_email_template_name` -- cetakan untuk badan HTML; awalan menjadi `None`, dimana kasus sebuah surel teks polos dikirim.

Secara awalan, `save()` mengumpulkan `context` dengan variabel sama yang [`PasswordResetView`](#django.contrib.auth.views.PasswordResetView) melewatkan ke konteks surelnya.

#### `class SetPasswordForm`

Formulir yang membiarkan pengguma merubah sandi mereka tanpa memasukkan sandi lama.

#### `class UserChangeForm`

Sebuah formulir digunakan di antarmuka admin untuk merubah infromasi dan perizinan pengguna.

#### `class UserCreationForm`

Sebuah [`ModelForm`](/id/4.1/topics/forms/modelforms/#django.forms.ModelForm) untuk membuat pengguna baru.

Itu mempunyai tiga bidang: `username` (dari model user), `password1`, dan `password2`. Itu memeriksa bahwa `password1` dan `password2` cocok, mensahkan sandi menggunakan [`validate_password()`](/id/4.1/topics/auth/passwords/#django.contrib.auth.password_validation.validate_password), dan menyetel sandi pengguna menggunakan [`set_password()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.set_password).

### Pembuktian keaslian data di cetakan

Pengguna masuk saat ini dan perizinan mereka dibuat tersedia di [template context](/id/4.1/ref/templates/api/) ketika anda menggunakan [`RequestContext`](/id/4.1/ref/templates/api/#django.template.RequestContext).

> **Secara teknis**
>
> Secara teknis, variabel-variabel ini hanya dibuat tersedia di konteks cetakan jika anda menggunakan pengolah konteks [`RequestContext`](/id/4.1/ref/templates/api/#django.template.RequestContext) dan `'django.contrib.auth.context_processors.auth'` adalah diadakan. Itu berada di berkas pengaturan dibangkitkan awalan. Untuk lebih, lihat [RequestContext docs](/id/4.1/ref/templates/api/#subclassing-context-requestcontext).

#### Pengguna

Ketika membangun sebuah cetakan [`RequestContext`](/id/4.1/ref/templates/api/#django.template.RequestContext), pengguna masuk saat ini, antara instance [`User`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User) atau instance [`AnonymousUser`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser), disimpan di variabel cetakan `{{ user }}`:

```html+django
{% 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.

#### Hak akses

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.

Menilai pencarian atribut-tunggal dari `{{ perms }}` sebagai boolean adalah wakil pada [`User.has_module_perms()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms). Sebagai contoh, untuk memeriksa jika pengguna masuk mempunyai perizinan apapun dalam aplikasi `foo`:

```
{% if perms.foo %}
```

Evaluating a two-level-attribute lookup as a boolean is a proxy to
[`User.has_perm()`](/id/4.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perm). For example,
to check if the logged-in user has the permission `foo.add_vote`:

```
{% if perms.foo.add_vote %}
```

Ini adalah beberapa contoh lengkap dari perizinan pemeriksaan dalam sebuah cetakan:

```html+django
{% 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:

```html+django
{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}
```

## Mengelola pengguna di admin

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.

### Membuat pengguna

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!

### Merubah sandi

Sandi pengguna tidak diperlihatkan di admin (maupun disimpan di basisdata), tetapi [password storage details](/id/4.1/topics/auth/passwords/) diperlihatkan. Disertakan di layar dari informasi ini adalah sebuah tautan pada sebuah formulir rubah sandi yang mengizinkan admin merubah sandi pengguna.