REMOTE_USERLink to this heading#Ten dokument opisuje jak zrobić użytek z zewnętrznych źródeł uwierzytelniania (gdzie Web serwer ustawia zmienną środowiskową REMOTE_USER) w twoich aplikacjach Django. Ten typ sposobu na uwierzytelnianie można zazwyczaj spotkać na stronach intranetowych z rozwiązaniami pojedynczego logowania takimi jak IIS i Integrated Windows Authentication lub Apache i mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi itp.
Kiedy serwer WWW zajmuje się uwierzytelnianiem, zazwyczaj ustawia zmienną środowiskową REMOTE_USER do użycia w aplikacji bazowej. W Django, REMOTE_USER jest udostępniony w atrybucie request.META `. Django może być skonfigurowane do wykorzystania wartości ``REMOTE_USER` za pomocą RemoteUserMiddleware lub PersistentRemoteUserMiddleware, oraz RemoteUserBackend` klas znajdujących się w django.contrib.auth.
Najpierw musisz dodać django.contrib.auth.middleware.RemoteUserMiddleware do ustawienia MIDDLEWARE po django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "django.contrib.auth.middleware.RemoteUserMiddleware",\n "...",\n]\nNastępnie musisz zamienić ModelBackend na RemoteUserBackend w ustawieniu AUTHENTICATION_BACKENDS:
AUTHENTICATION_BACKENDS = [\n "django.contrib.auth.backends.RemoteUserBackend",\n]\nW takiej konfiguracji RemoteUserMiddleware wykryje nazwę użytkownika w request.META['REMOTE_USER'] i będzie autentykował ją i automatycznie logował tego użytkownika przy pomocy RemoteUserBackend.
Miej świadomość, że ta konkretna konfiguracja wyłącza autentykację z domyślnym ModelBackend. To oznacza, że jeśli wartość REMOTE_USER nie jest ustawiona, wtedy użytkownik nie jest w stanie się zalogować, nawet używając interfejsu panelu administracyjnego Django. Dodanie 'django.contrib.auth.backends.ModelBackend' do listy AUTHENTICATION_BACKENDS będzie używać ModelBackend jako fallbacku, jeśli nie ma REMOTE_USER, co rozwiąże te problemy.
Zarządzanie użytkownikami Django, tak jak widok w contrib.admin i polecenie createsuperuser nie jest zintegrowane ze zdalnymi użytkownikami. Te interfejsy pracują z użytkownikami przechowywanymi w bazie bez względu na AUTHENTICATION_BACKENDS.
Jeśli twój mechanizm uwierzetelniania używa niestandardowego nagłówka HTTP ani REMOTE_USER, możesz stworzyć podklasę RemoteUserMiddleware i ustawić atrybut header na pożądany klucz request.META. Na przykład:
from django.contrib.auth.middleware import RemoteUserMiddleware\n\n\nclass CustomHeaderMiddleware(RemoteUserMiddleware):\n header = "HTTP_AUTHUSER"\nJeśli potrzebujesz więcej kontroli, możesz stworzyć swój własny backendowy system uwierzetelniania dziedziczący z RemoteUserBackend i przeładowujący jeden lub więcej jego atrybutów i metod.
REMOTE_USER tylko na stronach logowaniaLink to this heading#Middleware uwierzytelniający RemoteUserMiddleware zakłada, że nagłówek REMOTE_USER żądania HTTP jest obecny we wszystkich uwierzytelnionych żądaniach. To może być oczekiwane i praktyczne, kiedy użyty jest mechanizm Basic HTTP Auth z htpasswd lub jemu podobne, ale z metodą uwierzytelnienia Negotiate (GSSAPI/Kerberos) lub innymi metodami niewrażliwymi na zasoby, uwierzytelnianie we front-endowym serwerze HTTP jest zazwyczaj tylko przygotowaniem dla jednego lub kilku URLi logowania i po udanym uwierzytelnieniu aplikacja ma za zadanie samodzielnie utrzymać uwierzytelnioną sesję.
PersistentRemoteUserMiddleware dostarcza wsparcia dla tego przypadku użycia. Będzie utrzymywać uwierzetelnioną sesję dopóki użytkownik wprost się nie wyloguje. Klasa może być użytka jako zamiennik RemoteUserMiddleware w powyższej dokumentacji.