Otentikasi menggunakan REMOTE_USER
¶
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
.
Pengaturan¶
Pertama, andaharus menambahkan django.contrib.auth.middleware.RemoteUserMiddleware
pada pengaturan MIDDLEWARE
setelah django.contrib.auth.middleware.AuthenticationMiddleware
:
MIDDLEWARE = [
'...',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.RemoteUserMiddleware',
'...',
]
Selanjutnya, anda harus mengganti ModelBackend
dengan RemoteUserBackend
di pengaturan AUTHENTICATION_BACKENDS
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.RemoteUserBackend',
]
Dengan 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
.
Catatan
Sejak RemoteUserBackend
warisan dari ModelBackend
, anda akan masih mempunyai semua pemeriksaan perizinan sama yang diterapkan dalam ModelBackend
.
Pengguna dengan is_active=False
tidak akan diizinkan mengotentifikasi. Gunakan AllowAllUsersRemoteUserBackend
jika anda ingin mengizinkan mereka.
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
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = 'HTTP_AUTHUSER'
Peringatan
Sangat berhati-hatilah jika menggunakan subkelas RemoteUserMiddleware
dengan kepala HTTP penyesuaian. Anda harus pastikan bahwa peladen jaringan paling depan anda selalu disetel atau memotong kepala itu berdasarkan pada pemeriksaan pembuktian keaslian yang sesuai, jangan pernah mengizinkan pengguna-akhir mengajukan nilai kepala tiruan (atau "palse"). Sejak kepala HTTP X-Auth-User
dan X-Auth_User
(sebagai contoh) keduanya menormalkan ke kunci HTTP_X_AUTH_USER
dalam request.META
, anda harus juga memeriksa bahwa peladen jaringan anda tidak mengizinkan kepala palsu menggunakan garis bawah di tempat atau strip.
Peringatan ini tidak berlaku pada RemoteUserMiddleware
dalam konfigurasi awalnya dengan header = 'REMOTE_USER'
, sejak sebuah kunci tidak dimulai dengan HTTP_
dalam request.META
dapat hanya disetel dengan peladen WSGI anda, bukan secara langsung dari kepala meminta HTTP.
Jika anda butuh lebih kendali, anda dapat membuat backend pembuktian keaslian sendiri yang mewarisi dari RemoteUserBackend
dan menimpa satu atau lebih atribut dan metodenya.
Menggunakan REMOTE_USER
hanya pada halaman masuk¶
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.