Bagaimana mengotentikasi menggunakan REMOTE_USER

Dokumen in imenggambarkan bagaimana membuat sumber autentifikasi luar (dimana peladen jaringan menyetel variabel lingkungan REMOTE_USER) dalam aplikasi Django anda. Jenis solusi autentifikasi ini khususnya dilihat pada situs intranet dengan solusi sistem masuk tunggal seperti IIS dan Integrated Windows Authentication atau Apache dan mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi, dll.

Ketika peladen jaringan mengurus autentifikasi dia khususnya menyetel variabel lingkungan REMOTE_USER untuk digunakan dalam aplikasi pokok. Dalam Django, REMOTE_USER dibuat tersedia dalam atribut the request.META . Django dapat dikonfigurasi untuk memanfaatkan nilai REMOTE_USER menggunakan RemoteUserMiddleware atau PersistentRemoteUserMiddleware, dan kelas-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

Middleware autentifikasi RemoteUserMiddleware beranggapan bahwa kepala peminta HTTP REMOTE_USE hadir dengan semua permintaan terautentifikasi. Itu mungkin diharapkan dan praktis ketika Basic HTTP Auth dengan htpasswd atau mekanisme yang mirip digunakan, tetapi dengan Negotiate (GSSAPI/Kerberos) atau metode otentikasi sumber daya intensif lainnya, autentifikasi dalam peladen HTTP font-end biasanya hanya menyetel untuk satu atau sedikit URL masuk, dan setelah autentifikasi berhasil, aplikasi diharapkan merawat sesu autentifikasi itu 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.