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.
In primo luogo, devi aggiungere la classe django.contrib.auth.middleware.RemoteUserMiddleware nel file settings.py MIDDLEWARE posizionato dopo la classe django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "django.contrib.auth.middleware.RemoteUserMiddleware",\n "...",\n]\nPoi, devi sostituire ModelBackend con RemoteUserBackend nella impostazione di 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.
Sii cosciente che questa particolare configurazione disabilita l’autenticazione con il ModelBackend di default. Questo significa che se il valore di REMOTE_USER non è impostato, l’utente non potrà fare log in, anche utilizzando l’interfaccia di amministrazione di Django. Aggiungendo 'django.contrib.auth.backends.ModelBackend' all’elenco AUTHENTICATION_BACKENDS si userà ModelBackend come ripiego se è assente REMOTE_USER , risolvendo questo inconveniente.
La gestione utenti di Django, come le view in contrib.admin e il comando di gestione createsuperuser , non si integrano con gli utenti remoti. Queste interfacce lavorano con gli utenti memorizzati nel database, indipendentemente dagli 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]\nSe hai necessità di più controllo, puoi creare il tuo backend di autenticazione che eredita da RemoteUserBackend e sostituisce uno o più dei suoi attributi e metodi.
REMOTE_USER solo sulle pagine di loginLink to this heading#Il RemoteUserMiddleware presuppone che l’intestazione HTTP REMOTE_USER sia presente in tutte le richieste che necessitano di autenticazione. Può essere quindi usato quando si ha a che fare con il Basic HTTP Auth con htpasswd o altri semplici meccanismi; quando invece si usa Negotiate (GSSAPI/Kerberos) o un altro metodo di autenticazione che richiede maggiori risorse, l’autenticazione nel server HTTP di front-end è normalmente utilizzata in ambienti ristretti con pochi URL di accesso, e dopo un’autenticazione riuscita, si suppone che l’applicazione mantenga autonomamente la sessione autenticata.
PersistentRemoteUserMiddleware fornisce supporto per questo caso d’uso. Mantiene la sessione autenticata fino ad un logout esplicito dell’utente. La classe può essere usata in sostituzione in cascata di RemoteUserMiddleware nella documentazione di cui sopra.