Аутентификация на основе OpenID в Angular.js(с использованием флеш-памяти)

Ответ 1

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

Напоминаем, что у вас есть приложение AngularJS и посмотрите, как работает обмен аутентификацией OpenID:

• Пользователь вводит URL OpenID в форме входа и отправляется на сервер
• Сервер получает URL OpenID и отвечает перенаправлением на провайдер OpenID. Переадресация включает некоторые аргументы, включая URL-адрес обратного вызова.
• Поставщик OpenID предлагает пользователю ввести учетные данные для входа, а затем разрешить совместное использование его/ее идентификации с помощью серверного приложения.
• Поставщик OpenID отвечает перенаправлением обратно в приложение по URL-адресу, указанному в качестве обратного вызова на шаге 2, и предоставляет доступную ему информацию о пользователе, таком как идентификатор, адрес электронной почты, имя пользователя и т.д.
• Теперь сервер имеет информацию о пользователе и может найти пользователя в своей собственной пользовательской базе данных с помощью уникального идентификатора, адреса электронной почты или другого идентификатора. На этом этапе новая учетная запись может быть создана, если пользователь не известен приложению.
• Теперь, когда пользователь известен, сервер может написать файл cookie, который записывает, кто он/она, но обратите внимание, что это другая личность, чем та, что была на шаге 5. Информация о идентификационной информации, возвращаемая поставщиком OpenID, была полезной для найдите пользователя в своей собственной базе данных, так что теперь вы можете записать идентификатор пользователя в контексте вашего приложения. Это может быть идентификатор пользователя базы данных, адрес электронной почты или имя пользователя (если они уникальны) или токен, который может быть хэшем некоторой информации, имеющейся у пользователя.
• С cookie, написанным каждым новым запросом, который отправляется на сервер, поставляется с данными, которые идентифицируют аутентифицированного пользователя.

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

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

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

• URL-адрес корня, который служит для приложения Angular
• URL-адрес, инициирующий аутентификацию OpenID
• URL-адрес, который отправляется как обратный вызов поставщику OpenID

Таким образом, пользователь подключается к вашему корневому URL-адресу и получает приложение AngularJS, которое начинается в состоянии без аутентификации. В какой-то момент приложение Angular предложит пользователю войти в систему, используя форму с текстовым полем OpenID и кнопку отправки. Эти поля формы должны быть частью обычной HTML-формы, которая помещается на сервер, а не на стороне клиента Angular элементы, прикрепленные к контроллеру. Атрибут "действие" формы должен указывать на маршрут входа в сервер OpenID.

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

В конце шага 5 сервер разместил пользователя в базе данных приложения. Теперь сервер может выполнить перенаправление обратно на корневой URL-адрес, чтобы перезапустить приложение Angular. Если приложение необходимо перезагрузить в состоянии, которое не является начальным состоянием, тогда состояние восстановления может быть сохранено в хранилище на стороне клиента (например, файл cookie) перед запуском процесса аутентификации OpenID.

Но этого недостаточно, сервер также должен передать Angular некоторую информацию о пользователе, который вошел в систему. Один из способов сделать это - присоединить уникальный идентификатор пользователя или токен в строке запроса URL-адреса переадресации, к которому может обратиться приложение Angular. Это будет тот же самый фрагмент идентификатора, который был отправлен в файл cookie на шаге 6 выше.

Теперь приложение Angular перезагружается, может при необходимости восстановить его состояние и имеет идентификатор или токен, который идентифицирует зарегистрированного пользователя. Когда приложение должно выполнить запрос Ajax на сервер, он отправляет этот идентификатор или токен вместе с запросом. Сервер может проверить его и вернуть 401, если он признан недействительным, или если у него есть срок действия и срок его действия истек.

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

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

Очень важно: все обмены между приложением Angular и сервером Flask, которые содержат информацию о пользователе, должны выполняться через защищенный HTTP. Если ваши идентификаторы или жетоны не будут перемещаться в обычном тексте.