REMOTE_USERLink to this heading#Dokumen ini menjelaskan bagaimana memanfaatkan sumber otentikasi eksternal (di mana server Web menetapkan variabel environment REMOTE_USER) dalam aplikasi Django Anda. Jenis solusi otentikasi biasanya terlihat di situs intranet, dengan solusi single sign-on seperti IIS dan Integrated Windows Authentication atau Apache dan mod_authnz_ldap, CAS, Cosign,` WebAuth`_, `mod_auth_sspi `_, dll
Ketika peladen Jaringan mengurus pembuktian keaslian dia khususnya menyetel variabel lingkungan REMOTE_USER untuk digunakan dalam aplikasi pokok. Dalam Django, REMOTE_USER adalah dibuat tersedia dalam atribut request.META. Django dapat dikonfigurasikan untuk memanfaatkan nilai REMOTE_USER menggunakan RemoteUserMiddleware atau``PersistentRemoteUserMiddleware``, dan kelas RemoteUserBackend ditemukan dalam django.contrib.auth.
Pertama, andaharus menambahkan django.contrib.auth.middleware.RemoteUserMiddleware pada pengaturan MIDDLEWARE setelah django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [\n '...',\n 'django.contrib.auth.middleware.AuthenticationMiddleware',\n 'django.contrib.auth.middleware.RemoteUserMiddleware',\n '...',\n]\nSelanjutnya, anda harus mengganti ModelBackend dengan RemoteUserBackend di pengaturan AUTHENTICATION_BACKENDS
AUTHENTICATION_BACKENDS = [\n 'django.contrib.auth.backends.RemoteUserBackend',\n]\nDengan pengaturan ini, RemoteUserMiddleware akan mengenali nama pengguna di request.META['REMOTE_USER'] dan akan mengecek keasliannya dan masuk-otomatis bagi pengguna menggunakan RemoteUserBackend.
Waspada bahwa setelan khusus ini meniadakan pembuktian keaslian dengan awal ModelBackend. Ini berarti bahwa jika nilai REMOTE_USER tidak disetel kemudian pengguna tidak dapat masuk, bahkan menggunakan antarmuka admin Django. Menambahkan 'django.contrib.auth.backends.ModelBackend' pada daftar AUTHENTICATION_BACKENDS akan menggunakan ModelBackend sebagai alternatif jika REMOTE_USER tidak hadir, yang akan menyelesaikan masalah ini.
Pengelola pengguna Django, seperti tampilan dalam perintah pengelola contrib.admin dan the createsuperuser, tidak dipadukan dengan pengguna kendali jauh. Antarmuka ini bekerja dengan pengguna disimpan dalam basisdata tanpa memperhatikan AUTHENTICATION_BACKENDS.
Jika mekanisme pembuktian keaslian anda menggunakan kepala HTTP penyesuaian dan bukan REMOTE_USER, anda dapat men subkelas kan RemoteUserMiddleware dan menyetel atribut header ke kunci request.META yang diinginkan. Sebagai contoh:
from django.contrib.auth.middleware import RemoteUserMiddleware\n\nclass CustomHeaderMiddleware(RemoteUserMiddleware):\n header = 'HTTP_AUTHUSER'\nJika anda butuh lebih kendali, anda dapat membuat backend pembuktian keaslian sendiri yang mewarisi dari RemoteUserBackend dan menimpa satu atau lebih atribut dan metodenya.
REMOTE_USER hanya pada halaman masukLink to this heading#Pembuktian keaslian middleware RemoteUserMiddleware menganggap bahwa kepala permintaan HTTP REMOTE_USER mewakili dengan semua permintaan dibuktikan keaslian. Itu mungkin diharapkan dan secara praktiknya ketika Pembuktian Keaslian HTTP Dasar dengan htpasswd atau mekanisme sederhana lainnya digunakan, tetapi dengan Negotiate (GSSAPI/Kerberos) atau cara pembuktian keaslian intensif sumber daya lainnya, pembuktian keaslian dalam peladen HTTP depan biasanya hanya disetel untuk satu atau sedikit URL masuk, dan setelah berhasil dibuktikan keasliannya, aplikasi seharusnya menjaga sesi dibuktikan keasliannya sendiri.
PersistentRemoteUserMiddleware menyediakan dukungan untuk penggunaan kasus ini. Dia akan menjaga sesi dibuktikan keasliannya sampai keluar oleh pengguna. Kelas dapat digunakan sebagai pengganti dari RemoteUserMiddleware dalam dokumentasi diatas.