Открыть главное меню

Изменения

Глобальная авторизация в веб-системах

2282 байта добавлено, 15:50, 1 марта 2017
Нет описания правки
{{Box|{{Warning}} Ниже описывается Велосипедная Реализация SSO. В современном мире доступен OAuth2, про него можно почитать тут: [[Кратко об SSO через OAuth2]]}}
 
…или как реализовать простой [[rupedia:Технология единого входа|Single Sign-on]] в веб-системах.
! кто
! что делает
! width=35%| кому! width=45%| возможные ошибки
|-
|
|valign=top|
{{/С2}} не ответила или ответ не в формате JSON («по факту», а не по MIME-типу ответа):
: '''Сервер авторизации XXX недоступен или не отвечаетсо стороны системы {{/С1}}; код HTTP: XXX; MIME-тип ответа: XXX.'''
{{/С2}} ответила хешем в формате JSON, в котором присутствует поле «<tt>error</tt>» с непустым значением EEE:
: '''Сервер авторизации XXX сообщает об ошибке начала сессии авторизации: EEE.'''
|-
|valign=top align=center| 2
CHECK=0 и авторизовать пользователя в {{/С2}} невозможно.
: '''Сайт XXX ''(описание: TEXT)'' требует авторизации, а вы не авторизованы в {{/С2}}.''' (TEXT из предыдущего пункташага)
: Логично, если данное сообщение показывает пользователю {{/С2}}.
ID неизвестен клиенту:
: '''Попытка авторизации по неверному или устаревшему идентификатору сессии, либо сервер авторизации не смог передать данные учётной записи. Попробуйте ещё раз ''(ссылка)''.'''
 
<span style="color:red">Самая противная ошибка</span> — это ''Redirect-Loop'' — бесконечное перенаправление, которое можно спровоцировать, если при ошибке авторизации никак не сохранить факт ошибки в браузере пользователя (например, с помощью cookie) и вместо того, чтобы показать страницу с ошибкой, отправить пользователя обратно на шаг 2 (через шаг 1).
|}
В реализации протокола очень желательна обработка ошибок и их показ пользователю в удобном виде, чтобы не получалось, как в OpenID — «она утонула» © (то есть «произошла ошибка» без каких-либо деталей).
== Плюс FoF FoF_Sudo ==
(Тем кто читает это в вебе, можно в принципе и не читать)FoF_Sudo — беспарольная авторизация типа «от системы к системе».
Теперь Идея такая: пусть есть некая система типа (например [[lib:FeedOnFeeds|FoF]] — фидридер), в которой действует данный метод глобальной авторизацииглобальная авторизация (в качестве сервера выступает другая система), и которая пусть эта система должна авторизоваться на доверенных серверах, на которых эта глобальная авторизация тоже действует(в примере — FoF должен забирать защищённые RSS-ленты от имени разных пользователей). Естественно, Но при этом (!) пароль пользователя хранить в открытом виде в базе FoF при этом нельзя. Да если бы и было можно, да его в данных глобальной авторизации и его просто нету. Пример При этом нужно, чтобы при передаче такой ситуации — это FoF (фидридер) — он должен забирать RSSвот беспарольной авторизации какой-ленты пользователя, в которых то совершенно левый пользователь тоже авторизуетсяне смог сделать так же и зайти под произвольным пользователем.
Как это сделать? Ответ — одноразовые ключи на каждый запрос: * FoF видит в урле рсс’ки &fof_sudo=1(что_угодно). Что_угодно — совершенно что угодно, единственно, в случае FoF оно должно быть разное для разных пользователей, иначе FoF двух пользователей подпишет на один и тот же защищённый фид, а обновлять будет вообще как попало — то от имени одного, то от имени другого пользователя.* FoF генерирует случайный ID , запоминает соответствие этому ID пользователя и добавляет в запроскукис:
** Cookie: fof_sudo_id=ID
* Генератор рсс Система, к которой произошло обращение, видит cookie этот кукис (fof_sudo_id ) и делает обратный запрос к fof: /fof-sudo.php?id=ID* FoF отвечает данными пользователя, которые он помнит по этому ID, в формате JSON ({'user_name':'user@custis.ru'} ) и забывает ID* Генератор рсс принимает тот фактВнешняя система верит, что теперь он работает надо авторизоваться под юзером именем юзера user@custis.ru (и , например, отдаёт правильную рсс’куRSS’ку) {{Box|{{Warning}} И это тоже покрывается OAuth2.}}
[[Категория:Разработка]]