Аутентификация с REMOTE_USER ¶
В этом документе представлена процедура использования внешних источников аутентификации (для которых веб-сервер устанавливает переменную среды REMOTE_USER ) в ваших приложениях Django. Этот тип решения аутентификации является типичным для сайтов интрасети, с централизованными решениями аутентификации , как IIS и встроенная проверка подлинности Windows или Apache и mod_authnz_ldap , CAS , CoSign , WebAuth , загруженным модулем mod_auth_sspi и т.д.
Когда веб-сервер заботится об аутентификации, он обычно устанавливает переменную среды REMOTE_USER для базового приложения. В Django REMOTE_USER это доступно через атрибут request.META . Джанго может быть настроен на рудник для значений 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 . Например :
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 конфигурации по умолчанию с , поскольку ключ, который не начинается с in, может быть установлен только сервером WSGI, а не непосредственно из заголовка HTTP-запроса.header = 'REMOTE_USER' HTTP_ request.META
Если вам нужно больше навыков, вы можете создать собственный механизм аутентификации, который наследует RemoteUserBackend и переопределяет один или несколько его атрибутов и методов.
Используется REMOTE_USER только для страниц входа ¶
По промежуточного RemoteUserMiddleware слоя аутентификации предполагается, что заголовок HTTP-запроса REMOTE_USER присутствует для всех аутентифицированных запросов. Обычно это случается, когда используется такой механизм, как Basic HTTP Auth с htpasswd , но с такими методами аутентификации, как Negotiate (GSSAPI / Kerberos) или другими ресурсоемкими методами, аутентификация на внешнем HTTP-сервере обычно настраивается только для одного или нескольких URL-адресов входа; после успешной аутентификации приложение должно поддерживать аутентифицированный сеанс.
PersistentRemoteUserMiddleware поддерживает этот вариант использования. Он поддерживает аутентифицированный сеанс до явного отключения пользователя. Этот класс можно использовать в качестве замены RemoteUserMiddleware в приведенной выше документации без дальнейших изменений.