# Documentazione Django 6.0.7

# Come autenticarsi usando `REMOTE_USER`

This document describes how to make use of external authentication sources in your Django applications. This type of authentication solution is typically seen on intranet sites, with single sign-on solutions such as IIS and Integrated Windows Authentication or Apache and mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi, etc.

When the web server takes care of authentication it typically provides the authenticated user as `REMOTE_USER`. In Django, this value is made available in `request.META` (as `REMOTE_USER` when supplied as an environment variable, as in WSGI, or `HTTP_REMOTE_USER` when supplied via an HTTP header, as in ASGI). Django can be configured to make use of the `REMOTE_USER` value using the `RemoteUserMiddleware` or `PersistentRemoteUserMiddleware`, and `RemoteUserBackend` classes found in `django.contrib.auth`.

## Configurazione

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 = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "django.contrib.auth.middleware.RemoteUserMiddleware",
        "...",
    ]

Poi, devi sostituire `ModelBackend` con `RemoteUserBackend` nella impostazione di `AUTHENTICATION_BACKENDS`

    AUTHENTICATION_BACKENDS = [
        "django.contrib.auth.backends.RemoteUserBackend",
    ]

With this setup, `RemoteUserMiddleware` will detect the username in `request.META['REMOTE_USER']` (or `request.META['HTTP_REMOTE_USER']` under ASGI) and will authenticate and auto-login that user using 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`.

Nota

Poiché il `RemoteUserBackend` eredita da `ModelBackend`, avrai ancora tutto il controllo sui permessi che è implementato in `ModelBackend`.

Gli utenti con l’attributo `is_active=False` non avranno il permesso di autenticarsi. Usa `AllowAllUsersRemoteUserBackend` se vuoi permettere l’autenticazione.

If your authentication mechanism uses a custom HTTP header and not `REMOTE_USER`, you can subclass `RemoteUserMiddleware` and set the `header` attribute to the desired `request.META` key. For example:

`mysite/middleware.py`

     from django.contrib.auth.middleware import RemoteUserMiddleware

     class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
         header = "HTTP_AUTHUSER"

This custom middleware is then used in the `MIDDLEWARE` setting instead of `django.contrib.auth.middleware.RemoteUserMiddleware`:

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "mysite.middleware.CustomHeaderRemoteUserMiddleware",
        "...",
    ]

Avvertimento

`RemoteUserMiddleware` must not be deployed in configurations where a client can supply the header. You must be sure that your web server or reverse proxy always sets or strips that header based on the appropriate authentication checks, never permitting an end user to submit a fake (or «spoofed») header value.

Since the HTTP headers `X-Auth-User` and `X-Auth_User` (for example) both normalize to the `HTTP_X_AUTH_USER` key in `request.META`, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

Under WSGI, this warning doesn’t apply to `RemoteUserMiddleware` in its default configuration with `header = "REMOTE_USER"`, since a key that doesn’t start with `HTTP_` in `request.META` can only be set by your WSGI server, not directly from an HTTP request header.

This warning applies under ASGI in all configurations, because there is no equivalent for a WSGI server’s ability to place a trusted value in the environ. ASGI deployments must use a reverse proxy as described above when using this middleware.

Se 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.

## Usare `REMOTE_USER` solo sulle pagine di login

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.