В чем состоит разница между аутентификацией и авторизацией

Аутентификация и авторизация – две ключевые функции сервисной инфраструктуры для защиты конфиденциальных данных и операций от несанкционированного доступа со стороны злоумышленников.

Хотя эти два термина используются в одном контексте, они представляют собой принципиально разные понятия, поскольку осуществляют защиту взаимодополняющими способами.

Аутентификация

Аутентификация используется для подтверждения личности зарегистрированного пользователя. Проверка подлинности – это процесс проверки учетных данных: идентификатора пользователя (имени, адреса электронной почты, номера телефона) и пароля.

Если идентификатор и пароль совпадают с записями, хранящимися в базе данных системы, пользователю предоставляется доступ. В случае неправильного ввода данных программа вызывает предупреждение безопасности и блокирует вход. Если неудачных попыток будет несколько, система заблокирует саму учетную запись.

Факторы аутентификации

Метод стандартной аутентификации не может обеспечить абсолютную безопасность при входе пользователя в систему. Для создания более надежной защиты используются дополнительные категории учетных данных (факторов).

• Однофакторная аутентификация (SFA) – базовый, традиционный метод проверки подлинности с использованием только одной категории. Наиболее распространенным примером SFA являются учетные данные, связанные с введением имени пользователя и обычного пароля.

• Двухфакторная аутентификация (2FA) – двухступенчатый процесс проверки, который учитывает два разных типа пользовательских данных. Помимо логина и пароля, для обеспечения дополнительного уровня защиты, система может запросить особый код, присланный в SMS сообщении или в письме электронной почты.

• Многофакторная аутентификация (MFA)
  – самый современный метод проверки подлинности, который использует два, три (или больше) уровня безопасности. Категории всех уровней должны быть независимыми друг от друга, чтобы устранить любую уязвимость в системе. Финансовые организации, банки, правоохранительные органы пользуются многофакторной аутентификацией для защиты своих данных от потенциальных угроз.

Примером MFA является использование банковских карт. Наличие карты – первый фактор защиты, введение пин-кода – второй.

Авторизация

Происходит после того, как личность пользователя успешно аутентифицируется системой. Процесс авторизации определяет, имеет ли прошедший проверку человек доступ к определенным ресурсам: информации, файлам, базе данных. Факторы проверки подлинности, необходимые для авторизации, могут различаться в зависимости от уровня безопасности.

Например, процесс проверки и подтверждения идентификаторов сотрудников и паролей в организации называется аутентификацией, но определение того, какой сотрудник имеет доступ к определенным ресурсам, называется авторизацией. Предположим, что вы путешествуете и собираетесь сесть на самолет.

Заключение

Доступ к системе защищен как аутентификацией, так и авторизацией. Любая попытка доступа аутентифицируется путем ввода учетных данных, но она может быть принята только после успешной авторизации. И наоборот, если попытка аутентифицирована, но не авторизована, система запретит доступ к своим ресурсам.

Аутентификация в продукте

В продукте «Форсайт. Аналитическая платформа» доступно несколько методов аутентификации. Метод аутентификации выбирается в зависимости от требуемых мер безопасности.

Проверка учётных данных может производиться на сервере СУБД и/или в «Форсайт. Аналитическая платформа».

Настольное приложение

В настольном приложении доступны следующие базовые типы аутентификации:

Дополнительно доступны:

Доступность базовых методов аутентификации зависит от используемой СУБД:

Условные обозначения:

— тип аутентификации доступен;

— тип аутентификации недоступен.

Парольная аутентификация

Аутентификация производится с использованием логина и пароля. Доступна настройка парольной политики.

1. Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

2. «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

Ролевая аутентификация

Ролевая аутентификация аналогична парольной, производится с использованием логина и пароля. Доступ к объектам определяется по присвоенным пользователю ролям на сервере СУБД, которые совпадают с группами в «Форсайт. Аналитическая платформа».

1. Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

2. «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

3. СУБД возвращает список ролей пользователя. Список ролей сопоставляется со списком групп платформы. Пользователь получает права, соответствующие группам.

Доменная аутентификация

При доменной аутентификации пользователь подключается с использованием данных указанного доменного пользователя.

Для конечного пользователя доменная аутентификация не отличается от парольной, но упрощает администрирование пользователей при использовании доменных контроллеров.

1. Пользователь вводит доменное имя и пароль в «Форсайт. Аналитическая платформа».

2. «Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.

3. СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.

Интегрированная доменная аутентификация

Интегрированная доменная аутентификация аналогична обычной доменной аутентификации, но для авторизации будет использован доменный пользователь, под которым был совершен вход в операционную систему.

Метод аутентификации Kerberos:

При работе с СУБД Teradata интегрированная доменная аутентификация всегда осуществляется с использованием механизма аутентификации Kerberos. Для СУБД PostrgreSQL данный механизм может быть включён опциально в дополнительных параметрах соединения с репозиторием.

Для работы по протоколу Kerberos на клиентском компьютере необходимо установить MIT Kerberos (не входит в комплект поставки «Форсайт. Аналитическая платформа»).

1. Пользователь вводит доменное имя и пароль при входе в операционную систему.

2. «Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.

3. СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.

Двухфакторная аутентификация

Двухфакторная аутентификация — это метод аутентификации пользователя при помощи запроса аутентификационных данных двух разных типов.

В «Форсайт. Аналитическая платформа» двухфакторная аутентификация в качестве первого типа аутентификации использует любой базовый тип аутентификации, в качестве второго  — сертификат пользователя.

1. Пользователь выполняет базовую аутентификацию в «Форсайт. Аналитическая платформа».

2. После запроса пользователь предоставляет «Форсайт. Аналитическая платформа» сертификат.

3. При совпадении сертификата «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

Встроенная аутентификация

При встроенной аутентификации доступ к данным СУБД происходит под встроенным администратором. Проверка прав пользователя осуществляется на уровне платформы.

1. Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

2. «Форсайт. Аналитическая платформа» проверяет разрешения пользователя и обращается к СУБД, используя учётные данные встроенного администратора.

Веб-приложение

Для веб-приложения доступны все варианты аутентификации настольного приложения, при этом роль настольного приложения выполняет BI-сервер.

Дополнительно для веб-приложения доступны следующие методы аутентификации:

OAuth

Аутентификация через протоколы OAuth 1.1 и 2.0 позволяет пользователю авторизоваться под учётной записью сервиса Twitter, Google и других. Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.

1. Пользователь вводит логин и пароль соответствующего сервиса.

2. Поставщик данных (сервис) передает BI-серверу подтверждение аутентификации пользователя.

3. BI-сервер обращается к СУБД, используя данные встроенного администратора.

SAML

Протокол SAML позволяет совершать обмен аутентификационными данными между поставщиком аутентификации и «Форсайт. Аналитическая платформа». Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.

1. Пользователь предоставляет логин и пароль поставщику аутентификации.

2. Поставщик аутентификации передает «Форсайт. Аналитическая платформа» результат проверки данных пользователя.

3. «Форсайт. Аналитическая платформа» обращается к СУБД, используя данные встроенного администратора.

Гостевой вход

Для ознакомительной работы с веб-приложением возможна настройка гостевого входа. Пользователь сможет войти под заранее созданной гостевой учётной записью, не указывая учётных данных. При использовании гостевого входа рекомендуется ограничить права для гостевой учётной записи.

1. Пользователь переходит по гостевой ссылке.

2. BI-сервер обращается к СУБД, используя заранее введённые логин и пароль от гостевой учётной записи.

Аутентификация это что такое и какие разновидности бывают

Аутентификация – это средство защиты, работающее на основе установки личности и подтверждении подлинности лица, которое пытается получить доступ или авторизоваться в какой-либо системе. Сопоставляются сообщенный пользователем идентификатор и предъявленный. Обычно данный термин используется, когда идет речь о современных технологиях. К примеру, это может быть сопоставление пароля, придуманного пользователем, с паролем, вводимым позднее, при авторизации.

Аутентификация и ее разновидности

Существует весьма и весьма много разных вариаций аутентификации. Таким образом выделяются несколько разных ее уровней:

1. Слив данных не несет за собой никаких серьезных следствий ни для Интернет-источника, ни для самого пользователя. Обычно в таких ситуациях используют многоразовый пароль.
2. Утечка информации приведет к серьезным последствиям, а может даже и проблемам, поэтому в таком случае нужна более жесткая аутентификация. Ее можно обеспечить: одноразовыми паролями, дополнительной проверкой в виде кода при попытке авторизации.

Исходя из вышеперечисленной информации можно сказать, что абсолютно любую вариацию аутентификации можно разделить на взаимную и одностороннюю.

Базовая

Это самый простой вид. Информацию пользователя можно легко рассекретить, потому что пользовательские данные входят в состав запроса в интернете. Обычно не рекомендуется использовать эту вариацию даже в случае, если данные не несут абсолютно никакой существенной информации как для Интернет-ресурса, так и для пользователя. Эта нелюбовь к способу обусловливается тем, что большая часть пользователей интернета используют на всех платформах, где они зарегистрированы, один и тот же пароль. Поэтому у перехватчика информации будет высокая вероятность получить пароль от кредитной карточки или другого важнейшего Интернет-ресурса.

Дайджест

Данный вид работает на основе передачи данных в хэшированном состоянии. Ко всем паролям прикрепляется строчка, состоящая из различных символов. Так как хэш постоянно обновляется, это не дает перехватчику раскрыть данные, ведь каждое новое подключение образует новое значение пароля. Этот вид аутентификации используют большинство крупнейших браузеров в интернете.

HTTPS

Данный протокол позволяет шифровать абсолютно все данные, которые передаются между сервисом и интернет-клиентом. Единственным недостатком данного способа является замедление скорости интернета, то есть сайт грузит значительно дольше.

С использованием файлов Cookies

Небольшой массив данных, получивший название «Куки» располагается на компьютере пользователя. В процессе каждой попытки подключиться к ресурсу браузер посылает файлы Cookies в виде одной из частей HTTP-запроса. Эта технология используется в интернете очень часто.

Таким образом выделяются три наиболее популярные вариации аутентификаций. Их достаточно много, но эти – самые часто используемые

Что говорит Википедия

Аутентифика́ция (англ. authentication < греч. αὐθεντικός [authentikos] «реальный, подлинный» < αὐτός [autos] «сам; он самый») — процедура проверки подлинности.

Цитата из Википедии

В информатике

Аутентификация – проверка подлинности пользователя. Данная процедура достоверно определяет, что пользователь является именно тем, за кого себя выдает. Обычно в этом процессе проверяемая сторона предоставляет проверяющей какую-либо информацию, известную только им, и никому кроме. К примеру, пароль.

3DS

Особый вид защиты, представляющий собой защищенный протокол пользователя, путем ввода пароля двухфакторной авторизации. Главной задачей этой технологии является повышение безопасности проведения какой-либо сделки. При использовании такой аутентификации резко снижается вероятность использование кредитной карты без ведома ее владельца. Самой первой платежной системой, начавшей использовать данную технологию, является VISA. Остальные же, на ее примере, подключили ее уже после. Но даже такую, казалось бы, идеальную технологию, используют далеко не все магазины

Двухэтапная аутентификация

Двухэтапная аутентификация – это еще один способ защиты пользовательских данных, который основан на том, чтобы владелец знал не только пароль, но еще и обладал кодом, который можно узнать из соответствующего приложения на мобильном телефоне. Плюс в том, что, если даже, каким-то образом кто-то узнает Ваши данные и подберет логин и пароль, для входа ему потребуется своровать Ваш мобильный телефон, что значительно усложнит его работу.

Понять работу можно даже на реальном примере. При регистрации на какую-либо платформу Вы придумываете логин и пароль, но, если это какой-то очень важный ресурс, вы также можете добавить двухэтапную аутентификацию. Вы скачиваете на другое устройство (К примеру мобильный телефон) соответствующее приложение, настраиваете его, и при следующей авторизации на сайт с Вас потребуют не только придуманный Вами пароль, но еще код подключенной двухэтапной аутентификации.

Вывод

Проведя черту над всем вышесказанным можно уверенно сказать, что аутентификация – полезнейший процесс и одна из важнейших интернет-технологий. Она сразу же снижает вероятность того, что пользователя обманут или перехватят его информацию. Можно снизить риск быть обманутым еще сильнее. Для этого достаточно лишь своевременно менять пароли, и, конечно же, на всех сайтах использовать хоть чуть-чуть отличающиеся пароли.

Разница между аутентификацией и авторизацией

Authentication —

Аутентификация — процедура проверки подлинности, например:

проверка подлинности пользователя путём сравнения введённого им пароля (для указанного логина) с паролем, сохранённым в базе данных пользовательских логинов;

подтверждение подлинности электронного письма путём проверки цифровой подписи письма по открытому ключу отправителя;

проверка контрольной суммы файла на соответствие сумме, заявленной автором этого файла.

В русском языке термин применяется, в основном, в области информационных технологий.

Учитывая степень доверия и политику безопасности систем, проводимая проверка подлинности может быть односторонней или взаимной.

Обычно она проводится с помощью криптографических способов.

Аутентификацию не следует путать с авторизацией (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).

wiki

Authorization —

Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.

Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.

Авторизацию не следует путать с аутентификацией — процедурой проверки легальности пользователя или данных, например, проверки соответствия введённого пользователем пароля к учётной записи паролю в базе данных, или проверка цифровой подписи письма по ключу шифрования, или проверка контрольной суммы файла на соответствие заявленной автором этого файла.

Авторизация же производит контроль доступа к различным ресурсам системы в процессе работы легальных пользователей после успешного прохождения ими аутентификации.

wiki

Использование системы аутентификации пользователя — Документация Django 1.9

Этот раздел описывает использование аутентификации пользователя в Django с конфигурацией по умолчанию. Эта конфигурация покрывает требования большинства проектов, предоставляет надежный механизм работы с паролями и правами. Для проектов, которые требуют другой механизм авторизации, Django предоставляет возможность настроить механизм авторизации.

Django предоставляет возможности аутентификации и авторизации пользователей, обычно этот механизм называют системой аутентификации, т.к. эти функции связаны.

Объект пользователя

Объекты User — основа системы аутентификации. Они представляют пользователей сайта и используются для проверки прав доступа, регистрации пользователей, ассоциации данных с пользователями. Для представления пользователей в системе аутентификации используется только один класс, таким образом 'суперпользователи' или 'персонал' — это такие же объекты пользователей, просто с определёнными атрибутами.

Основные атрибуты пользователя:

Подробности смотрите в полном описании API, текущий раздел больше ориентирован на использование аутентификации.

Создание пользователей

Самый простой способ создать пользователя – использовать метод create_user():

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', '[email protected]', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

Если вы используете интерфейс администратора Django, вы можете создать пользователя через UI.

Создание суперпользователя

Суперпользователя можно создать с помощью команды createsuperuser:

$ python manage.py createsuperuser --username=joe [email protected]

Команда попросит ввести пароль. Пользователь будет создан сразу же по завершению команды. Если не указывать --username или --email, команда попросит ввести их.

Смена пароля

Django не хранит пароль в открытом виде, хранится только хеш (смотрите раздел о работе с паролями). Поэтому не советуем менять пароль напрямую. Именно по этой причине пользователь создается через специальную функцию.

Пароль можно сменить несколькими способами:

Команда manage.py changepassword *username* позволяет сменить пароль пользователя через консоль. Команда требует ввести пароль дважды. Если введённые значения совпадают, то пароль будет изменен. Если не указать имя пользователя, команда попробует найти пользователя с именем текущего системного пользователя.

Вы можете изменить пароль программно, используя метод set_password():

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

Если вы используете интерфейс администратора Django, вы можете изменить пароль, используя админку.

Django также предоставляет представления и формы, которые можно использовать при создании страниц для смены пароля пользователем.

При смене пароля будут завершены все сессии пользователя, если вы используете SessionAuthenticationMiddleware. Смотрите Сброс сессии при изменении пароля.

Аутентификация пользователей

authenticate(**credentials)

Для аутентификации пользователя по имени и паролю используйте authenticate(). Параметры авторизации передаются как именованные аргументы, по умолчанию это username и password, если пароль и имя пользователя верны, будет возвращен объект User. Если пароль не правильный, authenticate() возвращает None. Например:

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # the password verified for the user
    if user.is_active:
        print("User is valid, active and authenticated")
    else:
        print("The password is valid, but the account has been disabled!")
else:
    # the authentication system was unable to verify the username and password
    print("The username and password were incorrect.")

Примечание

Это низкоуровневый API для аутентификации; например, он используется в RemoteUserMiddleware. Если вы не пишете свою систему авторизации, скорее всего вам не понадобится его использовать. Если вам нужно будет ограничить доступ только авторизованным пользователям, используйте декоратор login_required().

Права доступа и авторизация

Django предоставляет простую систему проверки прав. Она позволяет добавлять права пользователю или группе пользователей.

Эта система используется админкой Django, но вы можете использовать её и в своем коде.

Админка использует проверку прав следующим образом:

• При доступе к странице добавления объекта проверяется наличие права “add” для объектов этого типа.

• При доступе к страницам просмотра списка объектов и изменения объекта проверяется наличие права “change” для объектов этого типа.

• При удалении объекта проверяется наличие права “delete” для объектов этого типа.

Права доступа можно добавлять не только типу объекта, но и конкретному объекту. Переопределив методы has_add_permission(), has_change_permission() и has_delete_permission() класса ModelAdmin, можно проверять права для конкретного объекта.

Модель User содержит связи многое ко многим с таблицами groups и user_permissions. Объект модели User работает со связанными моделями, как и другие модели Django:

myuser.groups = [group_list]
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions = [permission_list]
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()

Права доступа по умолчанию

Если добавить приложение django.contrib.auth в параметр конфигурации INSTALLED_APPS, оно добавит права доступа по умолчанию – “add”, “change” и “delete” – для каждой модели из установленных приложений.

Эти права доступа создаются при выполнении команды manage.py migrate. При первом выполнении migrate, после добавления django.contrib.auth в INSTALLED_APPS, права доступа по умолчанию создаются для всех старых и новых моделей. Впоследствии команда назначает стандартные права на новые модели при каждом запуске manage.py migrate (функция, которая создаёт права, подключена к сигналу post_migrate).

Предположим у вас есть приложение с app_label foo и модель Bar. Чтобы проверить права доступа, используйте:

• add: user.has_perm('foo.add_bar')
• change: user.has_perm('foo.change_bar')
• delete: user.has_perm('foo.delete_bar')

Модель Permission редко используется напрямую.

Группы

Модель django.contrib.auth.models.Group предоставляет возможность группировать пользователей, добавляя им набор прав доступа. Пользователь может принадлежать нескольким группам.

Пользователь, добавленный в группу, автоматически получает все права доступа этой группы. Например, если группа Site editors содержит права доступа can_edit_home_page, любой пользователь в этой группе получить это право доступа.

Также группы позволяют группировать пользователей, добавляя метки или дополнительные возможности. Например, вы можете создать группу 'Special users', и написать код, который предоставляет доступ к дополнительному функционалу сайта, или отправлять сообщения только пользователям этой группы.

Программное создание прав доступа

Кроме добавления своих прав доступа через класс Meta модели, вы также можете создать их напрямую. Например, создадим право доступа can_publish для модели BlogPost в приложении myapp:

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(codename='can_publish',
                                       name='Can Publish Posts',
                                       content_type=content_type)

Теперь его можно добавить объекту User через атрибут user_permissions или к объекту Group через атрибут permissions.

Кеширование прав доступа

ModelBackend кэширует права доступа объекта User после первого запроса на их получение. Такой подход удобен для цикла запрос-ответ, т.к. права доступа редко проверяются сразу же после их изменения (например, в админке). Если вы изменяете и проверяете права доступа в одном запросе или в тестах, проще всего заново загрузить объект User из базы данных. Например:

from django.contrib.auth.models import Permission, User
from django.shortcuts import get_object_or_404

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_bar')

    permission = Permission.objects.get(codename='change_bar')
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_bar')  # False

    # Request new instance of User
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_bar')  # True

    ...

Аутентификация в запросах

Django использует сессию и промежуточный слой для работы системы аутентификации в объекте запроса.

Этот механизм предоставляет атрибут request.user для каждого запроса, который возвращает текущего пользователя. Если текущий пользователь не авторизован, атрибут содержит экземпляр AnonymousUser, иначе экземпляр User.

Различить их можно с помощью метода is_authenticated():

if request.user.is_authenticated():
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

Как авторизовать пользователя

Если вы ходите привязать к сессии авторизованного пользователя, используйте функцию login().

login(request, user)

Чтобы авторизовать пользователя в представлении, используйте функцию login(). Она принимает объект HttpRequest и объект User. Функция login() сохраняет идентификатор пользователя в сессии, используя Django приложение для работы с сессиями.

Следует отметить, что любые данные установленные в анонимной сессии будут сохранены в сессии пользователя после его авторизации.

Данные пример показывает как вы можете использовать обе функции authenticate() и login():

from django.contrib.auth import authenticate, login

def my_view(request):
    username = request.POST['username']
    password = request.POST['password']
    user = authenticate(username=username, password=password)
    if user is not None:
        if user.is_active:
            login(request, user)
            # Redirect to a success page.
        else:
            # Return a 'disabled account' error message
            ...
    else:
        # Return an 'invalid login' error message.
        ...

Сначала вызывайте authenticate()

Когда вы самостоятельно авторизуете пользователя, вы должны успешно выполнить его аутентификацию с помощью функции authenticate() перед вызовом функции login(). Функция authenticate() устанавливает атрибут у класса User, указывающий бэкенд относительно которого был успешно аутентифицирован данный пользователь (обратитесь к документации на бэкенды для подробностей), эта информация понадобится позже для процесса авторизации. При попытке авторизации объекта пользователя, который был получен из базы напрямую, будет выброшена ошибка.

Как отменить авторизацию пользователя

logout(request)

Для отмены авторизации пользователя, который был авторизован с помощью функции django.contrib.auth.login(), следует использовать функцию django.contrib.auth.logout() в коде вашего представления. Функция принимает объект HttpRequest и не возвращает никаких значений. Например:

from django.contrib.auth import logout

def logout_view(request):
    logout(request)
    # Redirect to a success page.

Следует отметить, что функция logout() не выбрасывает никаких ошибок, если пользователь не был ранее авторизован.

При вызове функции logout() в рамках текущего запроса будут очищены все данные сессии. Все существующие данные будут стёрты. Это происходит для того, чтобы предотвратить возможность доступа к этим данным для другого пользователя, который будет использовать тот же браузер для своей авторизации. Если потребуется поместить некие данные в сессию, которые должны быть доступны пользователя сразу после отмены его авторизации, выполняйте это после вызова функции django.contrib.auth.logout().

Ограничение доступа для неавторизованных пользователей

Прямой путь

Самым простым способом ограничить доступ к страницам является использование метода request.user.is_authenticated() и, при необходимости, перенаправление на страницу авторизации:

from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated():
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

… или отображение сообщения об ошибке:

from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated():
        return render(request, 'myapp/login_error.html')
    # ...

Декоратор login_required

login_required(redirect_field_name=’next’, login_url=None)

Для краткости кода вы можете использовать декоратор login_required():

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

Функция login_required() делает следующее:

• Если пользователь не авторизован, то перенаправляет его на URL, указанный в параметре конфигурации settings.LOGIN_URL, передавая текущий абсолютный путь в запросе. Например: /accounts/login/?next=/polls/3/.

• Если пользователь авторизован, то выполняет код представления. В коде представления не требуется выполнять проверку авторизован ли пользователь или нет.

По умолчанию, в параметре "next" строки запроса хранится путь, по которому должен быть перенаправлен пользователь в результате успешной аутентификации. Если вам потребуется использовать другое имя для этого параметра, то воспользуйтесь необязательным аргументом redirect_field_name декоратора login_required():

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

Следует отметить, что если вы воспользуетесь аргументом redirect_field_name, то вам скорее всего потребуется внести изменения в ваш шаблон авторизации, так как переменная контекста шаблона, которая содержит путь перенаправления, будет использовать значение аргумента redirect_field_name в качестве своего ключа, а не стандартное значение "next".

Декоратор login_required() также принимает необязательный аргумент login_url. Например:

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

Следует отметить, что если вы не укажите аргумент login_url, то вам потребуется проверить параметр конфигурации settings.LOGIN_URL и ваше представление для авторизации соответственно настроены. Например, пользуясь стандартным поведением, добавьте следующие строки к вашей схеме URL:

from django.accounts/login/$', auth_views.login),

Параметр конфигурации settings.LOGIN_URL также принимает имена представлений и именованные шаблоны URL. Это позволяет вам свободно переносить ваше представление для авторизации пользователя внутри схемы URL без необходимости изменения настроек.

Примечание

Декоратор login_required() не проверяет свойство is_active объекта пользователя.

См.также

Если вы создаёте собственные представления для интерфейса администратора (или вам нужна та же аутентификация, что используются встроенными представлениями), то вам может пригодиться декоратор django.contrib.admin.views.decorators.staff_member_required() в качестве полезной альтернативы login_required().

Примесь LoginRequired

При использовании CBV представлений, вы можете получить поведение аналогичное login_required, используя примесь LoginRequiredMixin. Эта примесь должна быть указана в самом начале списка наследования.

class LoginRequiredMixin

Добавлено в Django 1.9.

Если представление использует эту примесь, все запросы от неаутентифицированных пользователей будут перенаправлены на страницу аутентификации или будет показана ошибка HTTP 403 Forbidden, это зависит от параметра raise_exception.

Вы можете установить любой из параметров AccessMixin для управления обработкой неаутентифицированных пользователей:

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Примечание

Подобно декоратору login_required(), эта примесь не проверяет свойство is_active объекта пользователя.

Ограничение доступа для авторизованных пользователей с помощью дополнительной проверки

Для ограничения доступа пользователям на основе определённых прав или какой-либо другой проверке, вам следует выполнять те же действия, что описаны выше.

Самым простым способом будет выполнение вашей проверки над request.user прямо в представлении. Например, эта проверка в представлении проверяет, что пользователь имеет адрес электронной почты на требуемом домене и, если это не так, перенаправляет его на страницу авторизации:

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...

user_passes_test(func, login_url=None, redirect_field_name=’next’)

Для удобства вы можете использовать декоратор user_passes_test, который выполняет перенаправление в случае, если проверяющая функция возвращает False:

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

Декоратор user_passes_test() принимает обязательный аргумент: функцию, которая принимает объект User и возвращает True, если пользователю разрешён доступ к просмотру страницы. Следует отметить, что декоратор user_passes_test() не выполняет автоматически проверку, что User прошёл авторизацию.

Декоратор user_passes_test() принимает для необязательных аргумента:

login_url

Позволяет определеть URL на который будут перенаправляться пользователя, которые нее смогут пройти проверку. Это может быть страница авторизации или по умолчанию это будет значение параметра конфигурации settings.LOGIN_URL, если вы не указали никакого значения.

redirect_field_name

Аналогично декоратору login_required(). Присвоение значения None удаляет соответствующее поле из URL, что может вам потребоваться при перенаправлении пользователей, которые не прошли проверку, на страницу отличную от страницы авторизации.

Например:

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...

class UserPassesTestMixin

Добавлено в Django 1.9.

При использовании CBV представлений, вы можете для этой цели применять UserPassesTestMixin.

test_func()

Вы можете переопределить метод test_func() класса для того, чтобы указать тест, который будет выполнен. Далее, вы можете указать любой параметр AccessMixin для настройки обработки неаутентифицированных пользователей:

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')

get_test_func()

Вы также можете переопределить метод get_test_func(), чтобы заставить примесь использовать по-другому именованную функцию для выполнения проверки (вместо test_func()).

Цепочка из UserPassesTestMixin

Из-за особенностей реализации UserPassesTestMixin, вы не можете выстроить цепочку наследования. Следующий пример не работает:

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...

Если TestMixin1 вызовет super() и примет результат в работу, то TestMixin1 не будет больше работать в одиночку.

Декоратор permission_required

permission_required(perm, login_url=None, raise_exception=False)

Довольно частой задачей является проверка наличия определённого права у пользователя. Для решения этой задачи Django предоставляет удобный декоратор permission_required():

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote')
def my_view(request):
    ...

Аналогично методу has_perm(), названия прав указываются в формате "<app label>.<permission codename>" (т.е., polls.can_vote для права на модель в приложении polls).

Декоратор также может принимать перечисление прав, в этом случае пользователь должен обладать всеми правами для того, чтобы получить доступ к представлению.

Следует отметить, что декоратор permission_required() также принимает необязательный аргумент login_url:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', login_url='/loginpage/')
def my_view(request):
    ...

Аналогично декоратору login_required() , по умолчанию значение для аргумента login_url соответствует значению параметра конфигурации settings.LOGIN_URL.

Если определён аргумент raise_exception, то декоратор будет выбрасывать исключение PermissionDenied с описанием 403 (HTTP Forbidden) представление вместо перенаправления на страницу авторизации.

Если вам надо использовать raise_exception, но также предоставить пользователям шанс сначала аутентифицироваться, вы можете использовать декоратор login_required():

from django.contrib.auth.decorators import login_required, permission_required

@permission_required('polls.can_vote', raise_exception=True)
@login_required
def my_view(request):
    ...

Изменено в Django 1.9:

В старых версиях, параметр permission работал только со строками, списками и кортежами, вместо строк и любых перечислений.

Примесь PermissionRequiredMixin

Для того, чтобы выполнить проверки для CBV представлений, вы можете использовать PermissionRequiredMixin:

class PermissionRequiredMixin

Добавлено в Django 1.9.

Эта примесь, подобно декоратору permisison_required, проверяет, есть ли у пользователя, который пытается получить доступ к представлению, все необходимые права. Вы можете указать право (или перечисление прав) с помощью параметра permission_required:

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.can_vote'
    # Or multiple of permissions:
    permission_required = ('polls.can_open', 'polls.can_edit')

Вы можете установить любые параметры AccessMixin для изменения обработки неаутентифированных пользователей.

Вы также можете переопределить эти методы:

get_permission_required()

Возвращает перечисления имён прав, используемых примесью. По умолчанию, это содержимое атрибута permission_required, при необходимости преобразованное в кортеж.

has_permission()

Возвращает булево значение, есть ли у текущего пользователя право выполнить декорированное представление. По умолчанию, возвращается результат вызова метода has_perms() со списком прав, полученных от метода get_permission_required().

Перенаправление неаутентифицированных запросов в CBV представлениях

Дл упрощения обработки правил доступа в CBV представлениях, примесь AccessMixin может быть использовано для перенаправления пользователя на страницу аутентификации или выбросить ошибку HTTP 403 Forbidden.

class AccessMixin

Добавлено в Django 1.9.

login_url

Стандартное значение для get_login_url(). По умолчанию, None, в этом случае метод get_login_url() возвратит settings.LOGIN_URL.

permission_denied_message

Стандартное значение для get_permission_denied_message(). По умолчанию, пустая строка.

redirect_field_name

Стандартное значение для get_redirect_field_name(). По умолчанию, "next".

raise_exception

Если этот атрибут установлен в True, то вместо перенаправления будет выброшено исключение PermissionDenied. По умолчанию, False.

get_login_url()

Возвращает URL, на который будут перенаправляться пользователи не прошедшие тест. Возвращает значение атрибута login_url, если оно определено, или settings.LOGIN_URL.

get_permission_denied_message()

При raise_exception равном True, этот метод может быть использован для управления сообщением об ошибке, которое будет передано в обработчик для отображения пользователю. По умолчанию, возврашает значение атрибута permission_denied_message.

get_redirect_field_name()

Возвращает имя параметра запроса, содержащий URL, на который должен быть перенаправлен пользователь в случае успешной авторизации. Если вы установите его в None, то параметр запроса не будет добавлен. По умолчанию, возвращает значение атрибута redirect_field_name.

handle_no_permission()

В зависимости от значения raise_exception, метод либо выбрасывает исключение PermissionDenied или перенаправляет пользователя на login_url, необязательно используя redirect_field_name, если оно установлено.

Сброс сессии при изменении пароля

Предупреждение

Данная защитная мера применяется только в случае, если активировано SessionAuthenticationMiddleware в параметре конфигурации MIDDLEWARE_CLASSES. Оно активировано, если файл settings.py был сгенерирован с помощью команды startproject на Django ≥ 1.7.

Проверка сессии станет обязательной в Django 1.10 вне зависимости от того, активировано ли SessionAuthenticationMiddleware. Если вы работаете над проектом до Django 1.7 или он был сгенерирован с помощью шаблона, который не включает SessionAuthenticationMiddleware, рассмотрите вариант активации этой возможности прежде чем продолжить чтение соглашений по обновлению.

Если ваша AUTH_USER_MODEL унаследована от класса AbstractBaseUser или реализует свой собственный метод get_session_auth_hash(), то аутентифицированные сессии будут содержать хэш, возвращённый этим методом. В случае AbstractBaseUser, это будет HMAC от поля с паролем. Если активирован SessionAuthenticationMiddleware, Django проверяет, что хеш, отправленный с каждым запросом, совпадает с хешом, вычисленным на стороне сервера. Это позволяет пользователю отключиться от всех его сессий с помощью изменения их пароля.

Стандартные представления для изменения пароля, поставляемые с Django, функция django.contrib.auth.views.password_change() и представление user_change_password в пакете django.contrib.auth, обновляют в сессии хэш пароля так, чтобы соответствующий пользователь не терял авторизацию. Если вы реализуете собственное представление для изменения пароля и желаете сохранить такое поведение, используйте эту функцию:

update_session_auth_hash(request, user)

Данная функция принимает текущий запрос и обновлённый объект пользователя из которого будет извлечён новый хэш сессии и соответственно обновляет хэш сессии. Пример использования:

from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

Если вы обновляете существующий сайт и требуется активировать SessionAuthenticationMiddleware без необходимости повторной авторизации всех ваших пользователей, вам сначала следует обновиться до Django 1.7 и подождать некоторое время, чтобы сессии были пересозданы естественным образом по мере авторизации пользователей, сессии будут содержать хэш, описанный ранее. Для всех пользователи, которые не были авторизованы и для которых были обновлены сессии с помощью проверочного хэша, будет сброшена текущая сессия и им потребуется выполнить повторную авторизацию.

Примечание

Так как метод get_session_auth_hash() использует параметр конфигурации SECRET_KEY, то обновление этого параметра приведёт к отмене всех существующих сессий на сайте.

Представления аутентификации

Django предоставляет несколько представлений, с помощью которых вы можете осуществлять управление авторизацией пользователей и их паролями. Представления используют ряд соответствующих форм, но вы можете передавать и свои формы.

Django не предоставляет стандартного шаблона для представлений аутентификации. Вы должны создать свой собственный шаблон для представлений, которые планируете использовать.change-password/’, auth_views.password_change, {‘template_name’: ‘change-password.html’} ) ]

Все представления возвращают экземпляр TemplateResponse, который позволяет легко изменять содержимое отклика перед его рендеринг7ом. Для этого следует обернуть представление внутри вашего собственного представления:

from django.contrib.auth import views

def change_password(request):
    template_response = views.password_change(request)
    # Do something with `template_response`
    return template_response

Для получения подробностей обратитесь к документации на TemplateResponse.

Все представления для аутентификации

Ниже приведён список со всеми представлениями пакета django.contrib.auth. Для получения информации о деталях реализации обратитесь к Использование представлений.

login(request, template_name=`registration/login.html`, redirect_field_name=, authentication_form, current_app, extra_context)

Имя URL: login

Обратитесь к документации на URL для получения информации по использованию именованных шаблонов URL.

Необязательные аргументы:

• template_name: Путь до шаблона, который будет использовать представление при авторизации пользователя. По умолчанию, registration/login.html.

• redirect_field_name: Имя GET поля, содержащего URL на который будет произведёно перенаправление после успешной авторизации. По умолчанию, next.

• authentication_form: Вызываемый объект (обычно, просто класс формы), использующийся для аутентификации. По умолчанию, AuthenticationForm.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

Вот, что делает представление django.contrib.auth.views.login:

• При вызове через GET, оно отображает форму для аутентификации, которая отправляет введённые данные через POST на тот же URL. Подробности далее.

• При вызове через POST с аутентификационными данными пользователя, оно пытается авторизовать пользователя. При успешной авторизации, представление перенаправляет на URL, указанный в next. Если параметр next не был предоставлен, происходит перенаправление на URL, содержащийся в параметре конфигурации settings.LOGIN_REDIRECT_URL (по умолчанию, /accounts/profile/). При невозможности авторизации, представление снова показывает форму.

Вашей обязанностью является предоставление HTML кода для шаблона, который по умолчанию называется registration/login.html. Данный шаблон принимает через контекст четыре переменных:

• form: Объект Form, который представляет AuthenticationForm.

• next: URL, на который будет осуществлено перенаправление после успешной авторизации. Можно также передавать строку запроса.

• site: Текущий Site, соответствующий параметру конфигурации SITE_ID. Если вы не активировали соответствующее приложение, переменной будет присвоен экземпляр RequestSite, который получает имя сайта и домен из текущего HttpRequest.

• site_name: Псевдоним для site.name. Если вы не активировали соответствующее приложение, переменной будет присвоено значение request.META['SERVER_NAME']. Для подробностей о работе с сайтами обратитесь к Фреймворк для сайтов.

Если потребуется отказаться от вызова шаблона registration/login.accounts/login/$', auth_views.login, {'template_name': 'myapp/login.html'}),

Вы также можете указать имя для GET поля, которое будет содержать URL для перенаправления после успешной авторизации пользователя, передав его в аргументе redirect_field_name в представление. По умолчанию, next.

Здесь показан пример содержимого шаблона registration/login.html, который вы можете использовать в качестве отправной точки. Он предполагает, что у вас есть шаблон base.html, который определяет блок content:

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'django.contrib.auth.views.login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login" />
<input type="hidden" name="next" value="{{ next }}" />
</form>

{# Assumes you setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

Если у вас реализован собственный механизм аутентификации (обратитесь к Собственная аутентификация) вы можете передать свою форму аутентификации в представление через параметр authentication_form. Данная форма должна принимать именованный аргумент request в её методе __init__ и предоставлять метод get_user, который должен возвращать объект аутентифицированного пользователя (метод будет вызываться только после успешной аутентификации).

logout(request, next_page=None, template_name='registration/logged_out.html', redirect_field_name='next', current_app=None, extra_context=None)

Отмена авторизации пользователя.

Имя URL: logout

Необязательные аргументы:

• next_page: URL, на который будет осуществлено перенаправление.

• template_name: Путь до шаблона, который будет использовать представление при прекращении авторизации пользователя. По умолчанию, registration/logged_out.html.

• redirect_field_name: Имя GET поля, содержащего URL на который будет произведёно перенаправление после отмены авторизации. По умолчанию, next. Переопределяет next_page, если данный параметр был передан в GET.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

Контекст шаблона:

• title: Локализованная строка “Logged out”.

• site: Текущий Site, соответствующий параметру конфигурации SITE_ID. Если вы не активировали соответствующее приложение, переменной будет присвоен экземпляр RequestSite, который получает имя сайта и домен из текущего HttpRequest.

• site_name: Псевдоним для site.name. Если вы не активировали соответствующее приложение, переменной будет присвоено значение request.META['SERVER_NAME']. Для подробностей о работе с сайтами обратитесь к Фреймворк для сайтов.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

logout_then_login(request, login_url=None, current_app=None, extra_context=None)

Отменяет авторизацию пользователя, затем перенаправляет на страницу авторизации.

Имя URL: Значения по умолчанию нет

Необязательные аргументы:

• login_url: URL страницы авторизации, на которую будет выполнено перенаправление. По умолчанию, settings.LOGIN_URL.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

password_change(request, template_name='registration/password_change_form.html', post_change_redirect=None, password_change_form=PasswordChangeForm, current_app=None, extra_context=None)

Позволяет пользователю изменить его пароль.

Имя URL: password_change

Необязательные аргументы:

• template_name: Путь до шаблона, который будет использовать представление при изменении пароля. По умолчанию, registration/password_change_form.html.

• post_change_redirect: URL, на который будет производится перенаправление после успешного изменения пароля.

• password_change_form: Собственная форма для изменения пароля, которая должна принимать именованный аргумент user. Форма должна вызывать функцию для изменения пароля пользователя. По умолчанию, PasswordChangeForm.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

Контекст шаблона:

password_change_done(request, template_name='registration/password_change_done.html', current_app=None, extra_context=None)

Страница, отображаемая после того, как пользователь изменил свой пароль.

Имя URL: password_change_done

Необязательные аргументы:

• template_name: Путь до шаблона. По умолчанию, registration/password_change_done.html.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

password_reset(request, is_admin_site=False, template_name='registration/password_reset_form.html', email_template_name='registration/password_reset_email.html', subject_template_name='registration/password_reset_subject.txt', password_reset_form=PasswordResetForm, token_generator=default_token_generator, post_reset_redirect=None, from_email=None, current_app=None, extra_context=None, html_email_template_name=None, extra_email_context=None)

Позволяет пользователю сбросить свой пароль, генерируя одноразовую ссылку, которая может быть использована для сброса пароля, и отправляя её на зарегистрированную электронную почто пользователя.

Если предоставленный адрес электронной почты не существует в системе, представление не будет выполнять отправку электронного сообщения, но и пользователь не получит никакого сообщения об ошибке. Это предотвращает утечку информации к потенциальным хацкерам. Если вам необходимо предоставлять сообщение об ошибке для этого случая, вы можете унаследовать форму PasswordResetForm и использовать аргумент password_reset_form.

Пользователь, отмеченный флагом отменённого пароля (см. set_unusable_password()), не может запросить сброс пароля. Так сделано, чтобы предотвратить неправильное использование при работе с внешними источниками аутентификации, например, с LDAP. Следует отметить, что они не получат никаких сообщений об ошибках, так как это вскрыло бы наличие аккаунта, и никакого сообщения на почту не будет отправлено.

Имя URL: password_reset

Необязательные аргументы:

• template_name: Путь до шаблона, который будет использоваться для отображения формы сброса пароля. По умолчанию, registration/password_reset_form.html.

• email_template_name: Путь до шаблона, который используется при генерации сообщения со ссылкой для сброса пароля, отправляемого на адрес электронной почты. По умолчанию, registration/password_reset_email.html.

• subject_template_name: Путь до шаблона, который используется при генерации заголовка сообщения со ссылкой для сброса пароля, отправляемого на адрес электронной почты. По умолчанию registration/password_reset_subject.txt.

• password_reset_form: Форма, которая будет использоваться для получения адреса электронной почты пользователя для сброса его пароля. По умолчанию, PasswordResetForm.

• token_generator: Экземпляр класса для проверки одноразовой ссылки. По умолчанию, default_token_generator, который является экземпляром django.contrib.auth.tokens.PasswordResetTokenGenerator.

• post_reset_redirect: URL, на который будет произведено перенаправление после успешного запроса на сброс пароля.

• from_email: Корректный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

• html_email_template_name: Путь до шаблона, который будет использоваться при генерации text/html блока электронного сообщения с ссылкой для сброса пароля. По умолчанию, сообщение в формате HTML не отправляется.

• extra_email_context: Словарь с контекстными данными, которые будут доступны в контексте шаблона сообщения.

Не рекомендуется, начиная с версии 1.8: Аргумент is_admin_site устарел и будет удалён в Django 1.10.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

Добавлено в Django 1.9:

Был добавлен email_email_context.

Контекст шаблона:

Контекст шаблона электронной почты:

• email: Псевдоним для user.email

• user: Текущий User, соответствующий полю email формы. Толька активные пользователи имеют возможность сбрасывать свои пароли passwords (User.is_active is True).

• site_name: Псевдоним для site.name. Если вы не активировали соответствующее приложение, переменной будет присвоено значение request.META['SERVER_NAME']. Для подробностей о работе с сайтами обратитесь к Фреймворк для сайтов.

• domain: Псевдоним для site.domain. Если вы не используете приложение для работы с сайтами, то значением будет request.get_host().

• protocol: http или https

• uid: Первичный ключ пользователя, закодированный в base 64.

• token: Токен для проверки корректности ссылки для сброса пароля.

Пример registration/password_reset_email.html (шаблон тела письма):

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

Такой же контекст используется для шаблона заголовка сообщения. Заголовок должен быть представлен одной строкой простого текста.

password_reset_done(request, template_name='registration/password_reset_done.html', current_app=None, extra_context=None)

Эта страница отображается после отправки пользователю письма с ссылкой для сброса его пароля. Данное представление вызывается по умолчанию, если представлению password_reset() не было явно передан URL post_reset_redirect.

Имя URL: password_reset_done

Примечание

Если предоставленный адрес электронной почты не существует в системе, пользователь не активирован или имеет деактивированный пароль, то пользователь будет перенаправляться на это представление, но никаких писем ему отправляться не будет.

Необязательные аргументы:

• template_name: Путь до шаблона. По умолчанию, registration/password_reset_done.html.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

password_reset_confirm(request, uidb64=None, token=None, template_name='registration/password_reset_confirm.html', token_generator=default_token_generator, set_password_form=SetPasswordForm, post_reset_redirect=None, current_app=None, extra_context=None)

Представляет форму для ввода нового пароля.

Имя URL: password_reset_confirm

Необязательные аргументы:

• uidb64: Идентификатор пользователя закодированный в base 64. По умолчанию, None.

• token: Токен для проверки корректности пароля. По умолчанию, None.

• template_name: Путь до шаблона, который использует представление для подтверждения пароля. По умолчанию, registration/password_reset_confirm.html.

• token_generator: Эеземпляр класса для проверки пароля. По умолчанию, default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.

• set_password_form: Форма, которая будет использоваться для установки пароля. По умолчанию, SetPasswordForm.

• post_reset_redirect: URL, на который будет произведено перенаправление после выполнения сброса пароля.По умолчанию, None.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Контекст шаблона:

• form: Форма (см. set_password_form выше) для установки нового пароля для пользователя.

• validlink: Булево значение. True, если ссылка (комбинация uidb64 и token) корректна и не была ещё использована.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

password_reset_complete(request, template_name='registration/password_reset_complete.html', current_app=None, extra_context=None)

Представление, которое информирует пользователя об успешном изменении пароля.

Имя URL: password_reset_complete

Необязательные аргументы:

• template_name: Путь до шаблона. По умолчанию, registration/password_reset_complete.html.

• current_app: Подсказка, указывающая на приложение к которому принадлежит текущее представление. Обратитесь к стратегии разрешения URL пространства имён для получения подробностей.

• extra_context: Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.

Не рекомендуется, начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Следует использовать request.current_app.

Вспомогательные функции

redirect_to_login(next, login_url=None, redirect_field_name='next')

Перенаправляет на страницу аутентификации и, в случае её успешного прохождения, затем перебрасывает на другой URL.

Обязательные аргументы:

Необязательные аргументы:

• login_url: URL страницы авторизации, на которую будет выполнено перенаправление. По умолчанию, settings.LOGIN_URL.

• redirect_field_name: Имя GET поля, содержащего URL на который будет произведёно перенаправление после отмены авторизации. Переопределяет next. если данный параметр был передан в GET.

Встроенные формы

Если вы не желаете использовать встроенные представления, но и формы переписывать не хотите, то система аутентификации предоставляет несколько встроенных форм, расположенных в django.contrib.auth.forms:

class AdminPasswordChangeForm

Форма, используемая в интерфейса администратора, для изменения пароля пользователя.

Принимает user в качестве первого неименованного параметра.

class AuthenticationForm

Форма для аутентификации пользователя.

Принимает request в качестве первого неименованного аргумента, который сохраняется в экземпляре формы для использования подклассами.

confirm_login_allowed(user)

По умолчанию, форма AuthenticationForm игнорирует пользователей у которых флаг is_active установлен в False. Вы можете изменить это поведение на проверку некого права пройти аутентификацию для пользователей. Выполните это с помощью своей формы, которая унаследована от AuthenticationForm и переопределяет метод confirm_login_allowed(). Этот метод должен выбрасывать исключение ValidationError в случае, если указанный пользователь не может проходить аутентификацию.

Например, позволяем всем пользователям проходить аутентификацию, невзирая на их статус активности:

from django.contrib.auth.forms import AuthenticationForm

class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
    def confirm_login_allowed(self, user):
        pass

Или позволяем только некоторым активным пользователям проходить аутентификацию:

class PickyAuthenticationForm(AuthenticationForm):
    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise forms.ValidationError(
                _("This account is inactive."),
                code='inactive',
            )
        if user.username.startswith('b'):
            raise forms.ValidationError(
                _("Sorry, accounts starting with 'b' aren't welcome here."),
                code='no_b_users',
            )

class PasswordChangeForm

Форма, через которую пользователь может менять свой пароль.

class PasswordResetForm

Форма для генерации и отправки одноразовой ссылки для сброса пользовательского пароля.

send_email(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)

Добавлено в Django 1.8.

Использует аргументы для отправки EmailMultiAlternatives. Может быть переопределена для изменения способа отправки сообщения пользователю.

Параметры:

subject_template_name – шаблон для заголовка. email_template_name – шаблон для тела письма. context – контекст передаётся в subject_template, email_template и html_email_template (если он не None). from_email – адрес электронной почты отправителя. to_email – адрес электронной почты пользователя. html_email_template_name – шаблон для HTML тела письма, по умолчанию, None, в этом случае отсылается обычный текст.

По умолчанию, save() наполняет context теми же переменными, что и функция

Аутентификация пользователя NTLM - Windows Server

• 27.09.2020
• 8 минут на чтение

В этой статье

В этой статье содержится некоторая информация об аутентификации пользователей NTLM.

Исходная версия продукта: Windows Server 2012 R2
Оригинальный номер базы знаний: 102716

Сводка

В этой статье обсуждаются следующие аспекты проверки подлинности пользователя NTLM в Windows:

• Хранение паролей в базе данных аккаунта
• Аутентификация пользователя с использованием пакета аутентификации MSV1_0
• Сквозная аутентификация

Дополнительная информация

Хранение паролей в базе данных аккаунта

Записи пользователей хранятся в базе данных диспетчера учетных записей безопасности (SAM) или в базе данных Active Directory.Каждая учетная запись пользователя связана с двумя паролями: паролем, совместимым с LAN Manager, и паролем Windows. Каждый пароль зашифрован и хранится в базе данных SAM или в базе данных Active Directory.

Пароль, совместимый с LAN Manager, совместим с паролем, который используется LAN Manager. Этот пароль основан на наборе символов производителя оригинального оборудования (OEM). Этот пароль не чувствителен к регистру и может содержать до 14 символов. Версия этого пароля OWF также известна как версия OWF или ESTD LAN Manager.Этот пароль вычисляется с использованием шифрования DES для шифрования константы открытым текстовым паролем. Пароль OWF LAN Manager имеет длину 16 байт. Первые 7 байтов пароля в открытом виде используются для вычисления первых 8 байтов пароля LAN Manager OWF. Вторые 7 байтов пароля в открытом виде используются для вычисления вторых 8 байтов пароля LAN Manager OWF.

Пароль Windows основан на наборе символов Unicode. Этот пароль чувствителен к регистру и может содержать до 128 символов.Версия OWF этого пароля также известна как пароль Windows OWF. Этот пароль вычисляется с использованием алгоритма шифрования RSA MD-4. Этот алгоритм вычисляет 16-байтовый дайджест строки переменной длины из байтов пароля в открытом виде.

У любой учетной записи пользователя может отсутствовать пароль LAN Manager или пароль Windows. Однако предпринимаются все попытки сохранить обе версии пароля.

Например, если учетная запись пользователя перенесена из базы данных LAN Manager UAS с помощью PortUas, или если пароль изменен из клиента LAN Manager или из клиента Windows for Workgroups, будет существовать только версия пароля LAN Manager.Если пароль установлен или изменен на клиенте Windows, и пароль не имеет представления LAN Manager, будет существовать только версия пароля для Windows. (Пароль может не иметь представления LAN Manager, поскольку длина пароля превышает 14 символов или символы не могут быть представлены в наборе символов OEM.)

Ограничения пользовательского интерфейса в Windows не позволяют паролям Windows превышать 14 символов. Последствия этого ограничения обсуждаются далее в этой статье.

В Windows 2000 с пакетом обновления 2 и в более поздних версиях Windows доступен параметр, позволяющий запретить Windows сохранять хэш вашего пароля LAN Manager. Для получения дополнительных сведений проверьте следующий номер статьи базы знаний Майкрософт:

299656 Как запретить Windows хранить хэш вашего пароля LAN Manager в Active Directory и локальных базах данных SAM

Примечание

Microsoft не поддерживает ручное или программное изменение базы данных SAM.

Аутентификация пользователя с использованием пакета аутентификации MSV1_0

Windows использует LsaLogonUser API для всех видов аутентификации пользователей. API LsaLogonUser аутентифицирует пользователей, вызывая пакет аутентификации. По умолчанию LsaLogonUser вызывает пакет аутентификации MSV1_0 (MSV). Этот пакет входит в состав Windows NT. Пакет аутентификации MSV хранит пользовательские записи в базе данных SAM. Этот пакет поддерживает сквозную аутентификацию пользователей в других доменах с помощью службы Netlogon.

Внутренне пакет аутентификации MSV разделен на две части. Первая часть пакета проверки подлинности MSV выполняется на компьютере, к которому выполняется подключение. Вторая часть выполняется на компьютере, содержащем учетную запись пользователя. Когда обе части работают на одном компьютере, первая часть пакета проверки подлинности MSV вызывает вторую часть без участия службы Netlogon. Первая часть пакета проверки подлинности MSV распознает необходимость сквозной проверки подлинности, поскольку переданное доменное имя не является его собственным доменным именем.Когда требуется сквозная аутентификация, MSV передает запрос в службу Netlogon. Затем служба Netlogon направляет запрос службе Netlogon на конечном компьютере. В свою очередь, служба Netlogon передает запрос другой части пакета проверки подлинности MSV на этом компьютере.

LsaLogonUser поддерживает интерактивный вход в систему, вход в службу и в сеть. В пакете проверки подлинности MSV все формы входа в систему передают имя учетной записи пользователя, имя домена, содержащего учетную запись пользователя, и некоторые функции пароля пользователя.Различные типы входа в систему представляют пароль по-разному, когда они передают его LsaLogonUser.

Для интерактивного входа в систему, пакетного входа в систему и входа в систему клиент входа в систему находится на компьютере, на котором выполняется первая часть пакета проверки подлинности MSV. В этом случае пароль в открытом виде передается LsaLogonUser и первой части пакета аутентификации MSV. Для входа в службы и в пакетном режиме диспетчер управления службами и планировщик задач обеспечивают более безопасный способ хранения учетных данных.

Первая часть пакета проверки подлинности MSV преобразует пароль в открытом виде как в пароль OWF LAN Manager, так и в пароль Windows NT OWF. Затем первая часть пакета передает пароль в открытом виде либо в службу NetLogon, либо во вторую часть пакета. Вторая часть затем запрашивает в базе данных SAM пароли OWF и проверяет их идентичность.

Для входа в сеть клиент, который подключается к компьютеру, ранее получил 16-байтовый запрос или "одноразовый номер".«Если клиент является клиентом LAN Manager, клиент вычислил 24-байтовый ответ на запрос, зашифровав 16-байтовый запрос 16-байтовым паролем OWF LAN Manager. Затем клиент LAN Manager передает этот« Ответ на запрос LAN Manager »в сервер. Если клиент является клиентом Windows, "ответ на вызов Windows NT" вычисляется с использованием того же алгоритма. Однако клиент Windows использует 16-байтовые данные Windows OWF вместо данных LAN Manager OWF. Клиент Windows затем передает на сервер ответ на запрос LAN Manager и ответ на запрос Windows NT.В любом случае сервер аутентифицирует пользователя, передавая LsaLogonUser API все следующие данные:

• Доменное имя
• Имя пользователя
• Оригинальный вызов
• Ответ на вызов LAN Manager
• Дополнительный ответ на вызов Windows NT

Первая часть пакета аутентификации MSV передает эту информацию без изменений во вторую часть. Во-первых, вторая часть запрашивает пароли OWF из базы данных SAM или из базы данных Active Directory.Затем вторая часть вычисляет ответ на вызов, используя пароль OWF из базы данных и переданный вызов. Затем вторая часть сравнивает вычисленный ответ на вызов с переданным ответом на вызов.

Примечание

NTLMv2 также позволяет клиенту отправлять вызовы вместе с использованием ключей сеанса, которые помогают снизить риск распространенных атак.

Как упоминалось ранее, любая версия пароля может отсутствовать в базе данных SAM или в базе данных Active Directory.Кроме того, любая версия пароля может отсутствовать при вызове LsaLogonUser. Если доступны как версия пароля для Windows из базы данных SAM, так и версия пароля для Windows из LsaLogonUser, используются обе версии. В противном случае для сравнения используется версия пароля LAN Manager. Это правило помогает обеспечить чувствительность к регистру при входе в сеть из Windows в Windows. Это правило также обеспечивает обратную совместимость.

Сквозная аутентификация

Служба NetLogon реализует сквозную аутентификацию.Выполняет следующие функции:

• Выбирает домен для передачи запроса аутентификации.
• Выбирает сервер в домене.
• Передает запрос аутентификации выбранному серверу.

Выбрать домен очень просто. Доменное имя передается LsaLogonUser. Доменное имя обрабатывается следующим образом:

• Если имя домена совпадает с именем базы данных SAM, аутентификация обрабатывается на этом компьютере.На рабочей станции Windows, которая является членом домена, имя базы данных SAM считается именем компьютера. На контроллере домена Active Directory имя базы данных учетных записей является именем домена. На компьютере, который не является членом домена, все запросы на вход обрабатываются локально.
• Если указанное доменное имя является доверенным в этом домене, запрос аутентификации передается в доверенный домен. На контроллерах домена Active Directory легко доступен список доверенных доменов.На члене домена Windows запрос всегда передается в основной домен рабочей станции, позволяя основному домену определять, является ли указанный домен доверенным.
• Если указанное доменное имя не является доверенным для домена, запрос аутентификации обрабатывается на компьютере, к которому осуществляется подключение, как если бы указанное доменное имя было этим доменным именем. NetLogon не делает различий между несуществующим доменом, ненадежным доменом и неправильно набранным доменным именем.

NetLogon выбирает сервер в домене с помощью процесса, называемого обнаружением. Рабочая станция Windows обнаруживает имя одного из контроллеров домена Windows Active Directory в своем основном домене. Контроллер домена Active Directory обнаруживает имя контроллера домена Active Directory в каждом доверенном домене. Компонент, который выполняет обнаружение, - это DC Locator, который работает в службе Netlogon. Локатор DC использует разрешение имен NETBIOS или DNS для поиска необходимых серверов, в зависимости от типа домена и настроенного доверия.

Как аутентифицировать пользователей

1. Главная >
2. Быстрый старт >
3. Как аутентифицировать пользователей

OneLogin поддерживает стандартные отраслевые подходы к аутентификации пользователей, но выбор правильного метода для вашего варианта использования часто является проблемой, если вы не знакомы с отраслевым жаргоном.

Это сводка параметров аутентификации OneLogin. Вы можете прочитать более подробную информацию и загрузить пример кода для каждого языка ниже.

1. Веб-приложение на стороне сервера с использованием страницы входа, размещенной в OneLogin

   • Рекомендуется для веб-приложений, в которых секрет клиента может быть скрыт от пользователя
   • Поддерживает SSO, MFA, принудительную смену пароля и автономные токены обновления из коробки

2. Одностраничное приложение (SPA), использующее страницу входа, размещенную в OneLogin

   • Для приложений на основе Javascript, которые могут не иметь серверного компонента
   • "Из коробки" поддерживает SSO, MFA и принудительную смену пароля.

3. Полная настраиваемая страница входа с поддержкой MFA

   • Рекомендуется при создании настраиваемого потока входа в систему
   • Поддерживает SSO, MFA и смену пароля, но требует дополнительной работы

4. Собственное или устаревшее приложение

   • Рекомендуется для собственных приложений или когда клиент не поддерживает расширенный интерактивный вход в систему
   • Нет поддержки SSO, MFA или принудительной смены пароля

Традиционное веб-приложение с размещенной страницей входа

Если у вас есть традиционное веб-приложение, размещенное на сервере, которое хочет переложить аутентификацию пользователей и управление идентификацией в OneLogin, тогда наш рекомендуемый подход использует OpenId Connect Authentication Flow .

Openid Connect - это отраслевой стандарт и передовой метод безопасной аутентификации пользователей.

В этом потоке пользователь перенаправляется на настраиваемую страницу входа, размещенную в OneLogin для аутентификации. После успешной аутентификации они перенаправляются в ваше приложение, которое выполняет вызов на стороне сервера для проверки их аутентификации и получения токена доступа. Маркер доступа используется для дополнительных вызовов на стороне сервера.

Openid Connect Authentication автоматически подстраивается под пользовательские политики безопасности, требования MFA и процессы входа в систему, которые вы определили в OneLogin, не требуя дополнительного кода.

Загрузите образец приложения с Github

Преимущества

• Поддерживает многофакторную аутентификацию и единый вход без дополнительного кода
• Автоматически поддерживает политики паролей на основе пользователей, принудительный сброс пароля и т. Д.
• поддерживает токены обновления для автономного доступа
• Использует самый безопасный поток OpenId Connect

Одностраничное приложение (SPA) с размещенной страницей входа

Если у вас есть SPA или приложение, написанное на Javascript, без API на стороне сервера, мы рекомендуем использовать OpenId Connect Implicit Flow .

Этот процесс аналогичен описанному выше процессу аутентификации OpenId Connect, но не требует проверки на стороне сервера для получения токена доступа.

Загрузите образец приложения с Github

Преимущества

• Поддерживает многофакторную аутентификацию, единый вход без дополнительного кода
• Автоматически поддерживает политики паролей на основе пользователей, принудительный сброс пароля и т. Д.
• Не требует взаимодействия на стороне сервера

Индивидуальная страница входа в систему

Используйте наш административный API, чтобы создать пользовательский интерфейс входа, если вы предпочитаете не использовать страницу входа, размещенную на OneLogin.

Требуется дополнительный код для решения всех случаев использования входа в систему, но необходимые API доступны.

Наши API показывают, требуется ли пользователю MFA, и мы предоставляем инструменты для проверки токенов, сброса паролей и т. Д. В конечном итоге вы несете ответственность за обеспечение безопасного процесса аутентификации.

Если вам не нравится дополнительная работа, рассмотрите возможность использования процесса аутентификации OpenId Connect, описанного выше.

Загрузите образец приложения с Github

Преимущества

• Полный контроль над входом в систему
• поддерживает многофакторную аутентификацию и единый вход

Собственные, доверенные или устаревшие приложения

Если вы работаете с родным или устаревшим приложением, которое ограничено использованием имени пользователя и пароля только для аутентификации и не поддерживает интерактивный вход в систему, то лучшим вариантом является OAuth3.0 Разрешение на использование пароля владельца ресурса.

Подобно указанной выше настраиваемой странице входа, этот метод аутентификации обеспечивает гибкий подход к входу в систему, но не имеет возможности принудительного сброса пароля или требования MFA.

Нет SSO. При использовании этого потока сеанс единого входа не устанавливается. Пользователь не может получить беспрепятственный доступ к другим приложениям.

Загрузите образец приложения с Github

Преимущества

• Гибкая поддержка устаревших приложений или случаев, когда интерактивный вход в систему невозможен

Настройка аутентификации в Django | Документация Django

Иногда вам нужно подключиться к другому источнику аутентификации. - то есть еще один источник имен пользователей и паролей или аутентификации методы.

Например, ваша компания может уже иметь настройку LDAP, в которой хранится имя пользователя. и пароль для каждого сотрудника. Это было бы проблемой как для сети администратор и сами пользователи, если у пользователей были отдельные учетные записи в LDAP и приложения на основе Django.

Итак, чтобы справиться с подобными ситуациями, система аутентификации Django позволяет вам подключите другие источники аутентификации. Вы можете изменить настройки Django по умолчанию схему на основе базы данных, или вы можете использовать систему по умолчанию в тандеме с другими системы.

Указание серверных модулей аутентификации¶

За кулисами Django поддерживает список «бэкэндов аутентификации», которые он проверяет аутентификацию. Когда кто-то звонит django.contrib.auth.authenticate () - как описано в Как войти пользователя в - Django пытается аутентифицироваться через все его механизмы аутентификации. Если первый метод аутентификации не работает, Django пробует второй и так далее, пока все серверные части не будут выполнены.

Список используемых механизмов аутентификации указан в AUTHENTICATION_BACKENDS параметр.Это должен быть список Python имена путей, которые указывают на классы Python, которые знают, как аутентифицироваться. Эти классы могут быть где угодно на вашем пути Python.

По умолчанию AUTHENTICATION_BACKENDS установлен на:

 ['django.contrib.auth.backends.ModelBackend']
 

Это основной сервер аутентификации, который проверяет базу данных пользователей Django. и запрашивает встроенные разрешения. Не обеспечивает защиты от атаки методом перебора через любой механизм ограничения скорости.Вы можете реализовать свой собственный механизм ограничения скорости в настраиваемом бэкэнде аутентификации или используйте механизмы, предоставляемые большинством веб-серверов.

Порядок AUTHENTICATION_BACKENDS имеет значение, поэтому если то же самое имя пользователя и пароль действительны для нескольких бэкэндов, Django остановится обработка при первом положительном совпадении.

Если серверная часть вызывает PermissionDenied исключение, аутентификация немедленно завершится ошибкой. Django не проверяет бэкэнды, которые следуют.

Примечание

После аутентификации пользователя Django сохраняет, какой бэкэнд использовался для аутентифицировать пользователя в сеансе пользователя и повторно использовать тот же бэкэнд на время этого сеанса всякий раз, когда доступ к текущему необходим аутентифицированный пользователь.Это фактически означает, что аутентификация источники кэшируются для каждого сеанса, поэтому, если вы измените

Аутентификация пользователя

Для UMLS REST API требуется учетная запись UMLS для аутентификации, описанной ниже. Если у вас нет учетной записи UMLS, вы можете подать заявку на получение лицензии на веб-сайте UMLS Terminology Services (UTS).

Аутентификация включает 3 шага и требует от вас создания и отправки форм с помощью вызовов POST. Вы можете найти Postman или ряд других инструментов, полезных для выполнения этих вызовов POST.Вы также можете проверить коллекции образцов Postman или образцы кода на Python, Java и Perl на Github, чтобы помочь вам. Мы также предлагаем демонстрацию аутентификации.

Чтобы получить помощь по выполнению вызовов аутентификации с помощью Postman, см. Наше руководство: UMLS REST API: аутентификация и вызов.

Шаг 1 : Получите ключ API из своего профиля UTS.

• Вы можете найти ключ API в области UTS «Мой профиль» после входа в систему. Ключ API остается активным, пока активна соответствующая учетная запись UTS.
• Если поле ключа API в вашем профиле UTS пусто, нажмите «Изменить профиль», установите флажок «Создать новый ключ API», затем прокрутите вниз и нажмите «Сохранить профиль». Ваш новый ключ API теперь доступен для использования.

** ПРИМЕЧАНИЕ **: использование имени пользователя и пароля с любым API, требующим аутентификации UTS, теперь не рекомендуется.

Шаг 2 : Получите билет для выдачи билетов (TGT). TGT действителен в течение 8 часов. Вам не нужен новый TGT для каждого вызова REST API.

• ПРИМЕЧАНИЕ. Вы должны включить имена ключей и значения ключей в закодированное по URL-адресу тело формы в свой вызов POST.

Используйте свой ключ API:

пример изгиба:

  curl -X POST https://utslogin.nlm.nih.gov/cas/v1/api-key -H 'content-type: application / x-www-form-urlencoded' -d apikey = {your_api_key_here}
  

Пример ответа на вызов POST для получения TGT (ваш TGT, конечно, будет уникальным):

  


 
  
 TGT создан 
 
 Service:   
 



  

Шаг 3 : Получите сервисный талон. Сервисный талон истекает через одно использование или через пять минут с момента создания, в зависимости от того, что наступит раньше.Для каждого вызова REST API требуется новый сервисный билет.

• ПРИМЕЧАНИЕ. Вы должны включить имена ключей и значения ключей в закодированное по URL-адресу тело формы в свой вызов POST.

Получение сервисного талона

пример изгиба:

  curl -X POST https://utslogin.nlm.nih.gov/cas/v1/tickets/{your_TGT_here} -H 'content-type: application / x-www-form-urlencoded' -d service = http% 3A% 2F% 2Fumlsks.nlm.nih.gov
  

Пример ответа на запрос POST для получения заявки на обслуживание:

  ST-134-HUbXGfI765aSj0UqtdvU-cas
  

Использование сервисных билетов

• Используйте билеты службы в качестве значения параметра запроса «ticket» в вызовах GET на https: // uts-ws.nlm.nih.gov/rest, например этот вызов для получения информации о CUI: C0018787: https://uts-ws.nlm.nih.gov/rest/content/current/CUI/C0018787?ticket=ST-134 -HUbXGfI765aSj0UqtdvU-cas

Подтверждение заявки на обслуживание

• Самый простой способ убедиться, что вы правильно реализовали аутентификацию, - это использовать браузер для перехода по следующему URL-адресу:
https://utslogin.nlm.nih.gov/cas/serviceValidate?ticket={ST}&service = http: // umlsks.nlm.nih.gov

• Если ваш билет службы действителен, вы получите строку, соответствующую вашему имени пользователя UMLS или ключу API, в зависимости от того, какой вариант вы использовали для создания билета на выдачу билетов.

  • Билет, созданный для неправильной службы, вернет следующую ошибку:
  • Недействительный билет службы вернет следующую ошибку: