Это обсуждалось много и долго, напрмер в посте… Реализовал свой велосипед межсайтовой авторизации.
Итак, вернемся к задачи:
есть несколько оригинальных проектов (project1,project2,projectN...), для которых должна быть единая авторизация. То есть, Пользователь залогинившись в проекте project1 имел доступ к ресурсам project2...projectN как авторизованный пользователь.
Как правило, подобные проекты лежат на едином хостинге и желательно чтоб имели общую (единую) регистрацию. Итак, если эти условия выполняются, то нижеописанное решение может продолжить жизнь и в Вашем проекте.
Ограничение: все проекты лежат в одном датацентре и находятся в одной локальной сети. Все проекты имеют единое хранидище для сессий и соответственно единый sid.
Договоримся, что:
Убиваем ключ в мемкеше или он умирает сам
а что если «чужой» решит залогинится по урлу project1.com/signin/#sid используя твой sid
да, это вполне возможно… Перехватить sid в урле можно с такой же вероятностю, что и перехватить куку, в которой хранится обычный sid.
Единая система регистрации предполагает, что пользователь регистрируется на sso.com
доступ к данным sso.com может быть из любого проекта. Все переходы при регистрации по аналогии с авторизацией, только урл другой: sso.com/registration/project1 (project1 показывает в каком дизайне отобразить регистрацию и куда вернуть порльзователя после регистрации)
Данные на sso.com можно (но вовсе не обязательно) хранить в key/value БД, например BerkleyDB.
PS. чтоб нас не выкидывало на форму логина слишком часто, надо использовать патч для мемкеша — autoprolongate ( про это в другом топике)
Данный патч делает автопролонгейт на такое же время после последнего обращение к данным.
Итак, вернемся к задачи:
есть несколько оригинальных проектов (project1,project2,projectN...), для которых должна быть единая авторизация. То есть, Пользователь залогинившись в проекте project1 имел доступ к ресурсам project2...projectN как авторизованный пользователь.
Как правило, подобные проекты лежат на едином хостинге и желательно чтоб имели общую (единую) регистрацию. Итак, если эти условия выполняются, то нижеописанное решение может продолжить жизнь и в Вашем проекте.
Ограничение: все проекты лежат в одном датацентре и находятся в одной локальной сети. Все проекты имеют единое хранидище для сессий и соответственно единый sid.
Договоримся, что:
- project.com — один из проектов.
- sso.com — сервер общей авторизации.
Залогинивание
- Пользователь на сайте project1.com жмет на ссылку Войти.
*** Как вариант возможен пост на урл sso.com/signin/project1/#sid
#sid — это номер сессиии
- идет редирект на sso.com/signin/project1/#sid
- Показывается дизайн сайта project1, дизайн проекта вычисляется по строке запроса
*** Если был пост, то показывать дизайн проекта не надо и сразу приступаем к авторизации - Пользователь вводит логин и пароль
*** Пункт не нужен если был пост - если авторизация успешна, то в мемкеш пишется сериализованный (в ввиде JSON) объет User,
ключом выступает #sid
далее идет редирект на урл project.com/welcome/#sid - делаем редирект на себя project.com/welcome без номера сессии (#sid)
- если авторизация не успешна, то редирект на progect1.com/error/401 (Не авторизован)
Авторизация
- Пользователь на сайте project1.com входит в любой раздел, который требует авторизации.
- На сервере в мемкеше проверяется ключ, где ключом является выступает номер сессии.
- Ключ существует, вытаскиваем все нужные данные из профиля (Объект User) и идем дальше
- Ключ не существует, редирект на форму логина сервера авторизации sso.com/signin/project1/#sid
Авторизация с другого проекта
- Пользователь на сайте project1.com входит в любой раздел, который требует авторизации.
- sso.com кладет в мемкеш по ключу sid объект User
- Пользователь переходит на project2.com/signin/#sid
- На сайте project2.com проверяется, если существует ключ #sid, то далее идет доступ ко всем разделам сайта.
Выход
Убиваем ключ в мемкеше или он умирает сам
не лишний Вопрос
а что если «чужой» решит залогинится по урлу project1.com/signin/#sid используя твой sid
да, это вполне возможно… Перехватить sid в урле можно с такой же вероятностю, что и перехватить куку, в которой хранится обычный sid.
Заключение
Единая система регистрации предполагает, что пользователь регистрируется на sso.com
доступ к данным sso.com может быть из любого проекта. Все переходы при регистрации по аналогии с авторизацией, только урл другой: sso.com/registration/project1 (project1 показывает в каком дизайне отобразить регистрацию и куда вернуть порльзователя после регистрации)
Данные на sso.com можно (но вовсе не обязательно) хранить в key/value БД, например BerkleyDB.
PS. чтоб нас не выкидывало на форму логина слишком часто, надо использовать патч для мемкеша — autoprolongate ( про это в другом топике)
Данный патч делает автопролонгейт на такое же время после последнего обращение к данным.
