# Documentação Django 6.0.7

# Como autenticar 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`.

## Configuração

Primeiro você deve adicionar `django.contrib.auth.middleware.RemoteUserMiddleware` no `MIDDLEWARE` definindo depois do `django.contrib.auth.middleware.AuthenticationMiddleware`:

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

Depois você deve substituir a `ModelBackend` por `RemoteUserBackend` na configuração `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`.

Esteja ciente de que essa definição em particular desabilita a autenticação com o padrão `ModelBackend`. Isso significa que se o valor de `REMOTE_USER` não estiver definido o usuário não conseguirá logar-se, mesmo utilizando a inteface do Django admin. Adicionando `django.contrib.auth.backends.ModelBackend` à lista `AUTHENTICATION_BACKENDS` ele será utilizado como um substituto se “REMOTE_USER” estiver ausente, e esse problema não acontecerá.

O gerenciamento de usuários do Django, bem como as views em `contrib.admin`, e o comando de gerenciamento `createsuperuser`, não fazem integração com usuários remotos. Esta interface trabalha com usuários armazenados no banco de dados independente do `AUTHENTICATION_BACKENDS`.

Nota

Um vez que `RemoteUserBackend` herda de `ModelBackend`, você ainda terá todos as mesmas permissões de verificação que estão implementadas em `ModelBackend`.

Usuários com `is_active=False` não serão permitidos a fazer a autenticação. Use `AllowAllUsersRemoteUserBackend` se você quiser permití-los.

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",
        "...",
    ]

Aviso

`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 você precisa de mais controle, é possível criar seu próprio “backend” de autenticação que herda de `RemoteUserBackend` e sobrescreve um ou mais de seus atributos e métodos.

## Usando `REMOTE_USER` apenas nas páginas de login.

O middleware de autenticação `RemoteUserMiddleware` assume que o cabeçalho `REMOTE_USER` da requisição HTTP está presente em todas as requisições autenticadas. Isso é esperado e até prático quando usado em uma autenticação HTTP básica com `htpasswd` ou um outro mecanismo simples, mas com uma requisição Negotiate (GSSAPI/Kerberos) ou outro método de autenticação de fontes intensivas, a autenticação no servidor HTTP de front-end é comumente configurada para uma ou algumas poucas URLS de login, e depois de uma autenticação bem sucedida, é esperado que a aplicação mantenha a sessão de autenticação por conta própria.

A classe `PersistentRemoteUserMiddleware` provê suporte para este caso de uso. Ele manterá a sessão de autenticação até o logout explícito do usuário. A classe pode ser usada como um substituto constante para `RemoteUserMiddleware` na documentação acima.