REMOTE_USERLink to this heading#This document describes how to make use of external authentication sources in\nyour Django applications. This type of authentication solution is typically\nseen on intranet sites, with single sign-on solutions such as IIS and\nIntegrated Windows Authentication or Apache and mod_authnz_ldap, CAS,\nWebAuth, mod_auth_sspi, etc.
\nWhen the web server takes care of authentication it typically provides the\nauthenticated user as REMOTE_USER. In Django, this value is made available\nin request.META (as REMOTE_USER when\nsupplied as an environment variable, as in WSGI, or HTTP_REMOTE_USER when\nsupplied via an HTTP header, as in ASGI). Django can be configured to make use\nof the REMOTE_USER value using the RemoteUserMiddleware or\nPersistentRemoteUserMiddleware, and\nRemoteUserBackend classes found in\ndjango.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]\nWith this setup, RemoteUserMiddleware will detect the username in\nrequest.META['REMOTE_USER'] (or request.META['HTTP_REMOTE_USER'] under\nASGI) and will authenticate and auto-login that user\nusing the 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.
If your authentication mechanism uses a custom HTTP header and not\nREMOTE_USER, you can subclass RemoteUserMiddleware and set the\nheader attribute to the desired request.META key. For example:
mysite/middleware.py from django.contrib.auth.middleware import RemoteUserMiddleware\n\n\n class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):\n header = "HTTP_AUTHUSER"\nThis custom middleware is then used in the MIDDLEWARE setting\ninstead of django.contrib.auth.middleware.RemoteUserMiddleware:
MIDDLEWARE = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "mysite.middleware.CustomHeaderRemoteUserMiddleware",\n "...",\n]\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.