Как выполнять аутентификацию с помощью REMOTE_USER
В этом документе описано, как использовать внешние источники аутентификации (в которых веб-сервер устанавливает переменную окружения REMOTE_USER) в приложениях Django. Такой способ аутентификации обычно применяется на сайтах интрасети с решениями для единого входа, такими как IIS и встроенная проверка подлинности Windows или Apache и mod_authnz_ldap, CAS, WebAuth, mod_auth_sspi и т. д.
Когда аутентификацию выполняет веб-сервер, он обычно устанавливает переменную окружения REMOTE_USER для использования в нижележащем приложении. В Django значение REMOTE_USER доступно в атрибуте request.META. Django можно настроить на использование значения REMOTE_USER с помощью классов RemoteUserMiddleware или PersistentRemoteUserMiddleware и RemoteUserBackend, находящихся в django.contrib.auth.
Настройка
Сначала добавьте django.contrib.auth.middleware.RemoteUserMiddleware в параметр MIDDLEWARE после django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE = [
"...",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.auth.middleware.RemoteUserMiddleware",
"...",
]
Затем замените ModelBackend на RemoteUserBackend в параметре AUTHENTICATION_BACKENDS:
AUTHENTICATION_BACKENDS = [
"django.contrib.auth.backends.RemoteUserBackend",
]
При такой настройке RemoteUserMiddleware обнаружит имя пользователя в request.META['REMOTE_USER'], выполнит аутентификацию и автоматически войдёт в систему от имени этого пользователя с помощью RemoteUserBackend.
Обратите внимание: такая конфигурация отключает аутентификацию с помощью стандартного ModelBackend. Это означает, что если значение REMOTE_USER не задано, пользователь не сможет войти в систему, даже через административный интерфейс Django. Добавление 'django.contrib.auth.backends.ModelBackend' в список AUTHENTICATION_BACKENDS позволит использовать ModelBackend в качестве запасного варианта, если REMOTE_USER отсутствует, что решит эту проблему.
Управление пользователями Django, например представления в contrib.admin и команда управления createsuperuser, не интегрировано с удалёнными пользователями. Эти интерфейсы работают с пользователями, хранящимися в базе данных, независимо от AUTHENTICATION_BACKENDS.
Примечание
Поскольку RemoteUserBackend наследуется от ModelBackend, вам по-прежнему будут доступны все те же проверки разрешений, которые реализованы в ModelBackend.
Пользователям с is_active=False будет запрещена аутентификация. Чтобы разрешить им вход, используйте AllowAllUsersRemoteUserBackend.
Если ваш механизм аутентификации использует пользовательский HTTP-заголовок вместо REMOTE_USER, можно создать подкласс RemoteUserMiddleware и задать атрибуту header нужный ключ request.META. Например:
mysite/middleware.py from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
header = "HTTP_AUTHUSER"
Затем используйте это пользовательское промежуточное ПО в параметре MIDDLEWARE вместо django.contrib.auth.middleware.RemoteUserMiddleware:
MIDDLEWARE = [
"...",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"mysite.middleware.CustomHeaderRemoteUserMiddleware",
"...",
]
Предупреждение
Будьте особенно осторожны, если используете подкласс RemoteUserMiddleware с пользовательским HTTP-заголовком. Необходимо убедиться, что ваш фронтенд-веб-сервер всегда устанавливает или удаляет этот заголовок в соответствии с надлежащими проверками аутентификации и ни в коем случае не позволяет конечному пользователю отправить поддельное значение заголовка. Поскольку HTTP-заголовки X-Auth-User и X-Auth_User (например) нормализуются в ключ HTTP_X_AUTH_USER в request.META, также проверьте, что ваш веб-сервер не позволяет подделывать заголовок, заменяя дефисы подчёркиваниями.
Это предупреждение не относится к RemoteUserMiddleware в конфигурации по умолчанию с header = 'REMOTE_USER', поскольку ключ, не начинающийся с HTTP_ в request.META, может быть установлен только вашим WSGI-сервером, а не напрямую из HTTP-заголовка запроса.
Если вам нужен более высокий уровень контроля, можно создать собственный бэкенд аутентификации, унаследовав его от RemoteUserBackend и переопределив один или несколько его атрибутов и методов.
Использование REMOTE_USER только на страницах входа
Промежуточное ПО аутентификации RemoteUserMiddleware предполагает, что HTTP-заголовок запроса REMOTE_USER присутствует во всех аутентифицированных запросах. Это может быть ожидаемым и практичным поведением при использовании базовой HTTP-аутентификации с htpasswd или аналогичных механизмов. Однако при использовании Negotiate (GSSAPI/Kerberos) или других ресурсоёмких методов аутентификации аутентификация на фронтенд-сервере HTTP обычно настраивается только для одного или нескольких URL-адресов входа, а после успешной аутентификации приложение должно самостоятельно поддерживать аутентифицированный сеанс.
PersistentRemoteUserMiddleware поддерживает этот сценарий использования. Оно будет поддерживать аутентифицированный сеанс до тех пор, пока пользователь явно не выйдет из системы. Этот класс можно использовать вместо RemoteUserMiddleware, описанного выше.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/6.0/howto/auth-remote-user/
