13 794
правки
Изменения
м
Для дополнительной защиты всё это можно просто пустить через HTTPS Как уже было сказано выше, данные авторизации — произвольные в JSON-формате. Однако, удобно специфицировать его чуть точнее: хеш, в котором есть поля <tt>user_name</tt> (SSLлогин), <tt>user_email</tt> (адрес электронной почты) и необязательные поля <tt>user_url</tt> (URL «домашней страницы» пользователя) и <tt>user_real_name</tt> («настоящее имя» пользователя). OpenID, на самом деле, работает похоже, но ''почему-то'' адски глючит и его страшно использовать на своих внутренних ресурсах. :) Что ещё нужно (TODO): обработка и передача описаний ошибок между серверами для их показа пользователю в удобном виде, чтобы не получалось, как в OpenID — «произошла ошибка» («она утонула» ©).
Нет описания правки
|}
И ID и ключ являются «секретными», но ID знают и сервера, и пользователь (ID передаётся в браузер), а ключ — только сами сервера. За счёт этого достигается безопасность: пользователь не может сам передать произвольные данные авторизации на сервер, не зная ключа. Для дополнительной защиты всё это можно просто пустить через HTTPS (SSL).
== Плюс FoF ==