Как аутентифицироваться с помощью REMOTE_USER
В этом документе описывается, как использовать внешние источники аутентификации (где веб-сервер устанавливает переменную среды REMOTE_USER) в ваших приложениях Django. Этот тип решения для аутентификации обычно используется на сайтах интрасети, с решениями единого входа, такими как IIS и Integrated Windows Authentication или 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 присутствует во всех аутентифицированных запросах. Это может быть ожидаемым и практичным, когда используется Basic HTTP Auth с htpasswd или подобными механизмами, но с Negotiate (GSSAPI/Kerberos) или другими ресурсоемкими методами аутентификации, аутентификация на веб-сервере на стороне клиента обычно настраивается только для одного или нескольких URL-адресов входа, и после успешной аутентификации приложение должно поддерживать сеанс аутентификации самостоятельно.
PersistentRemoteUserMiddleware предоставляет поддержку для этого случая использования. Он будет поддерживать сеанс аутентификации до явного выхода пользователя из системы. Класс может использоваться как замена RemoteUserMiddleware в приведенной выше документации.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/5.2/howto/auth-remote-user/
