Авторизация с использованием REMOTE_USER
Этот документ описывает, как использовать внешние источники аутентификации (где веб-сервер устанавливает переменную окружения REMOTE_USER) в ваших приложениях Django. Этот тип решения для аутентификации обычно используется на внутрисетевых сайтах с решениями единого входа, такими как IIS и интегрированная аутентификация Windows или Apache и mod_authnz_ldap, CAS, Cosign, WebAuth, mod_auth_sspi и т.д.
Когда веб-сервер отвечает за аутентификацию, он обычно устанавливает переменную окружения REMOTE_USER для использования в приложении. В Django, значение REMOTE_USER доступно в атрибуте request.META. Django можно настроить для использования значения REMOTE_USER с помощью классов RemoteUserMiddleware и RemoteUserBackend, которые находятся в django.contrib.auth.
Настройка
Сначала необходимо добавить django.contrib.auth.middleware.RemoteUserMiddleware в настройку MIDDLEWARE_CLASSES **после** django.contrib.auth.middleware.AuthenticationMiddleware:
MIDDLEWARE_CLASSES = (
'...',
'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.
Если ваш механизм аутентификации использует пользовательский HTTP-заголовок, а не REMOTE_USER, вы можете создать подкласс RemoteUserMiddleware и установить атрибут header на нужный ключ request.META. Например:
from django.contrib.auth.middleware import RemoteUserMiddleware
class CustomHeaderMiddleware(RemoteUserMiddleware):
header = 'HTTP_AUTHUSER'
Предупреждение
Будьте очень внимательны, если используете подкласс 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 и переопределить один или несколько его атрибутов и методов.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.8/howto/auth-remote-user/