ФорумПрограммированиеОбщие вопросы программирования → Сервис "Пасспорт юзера" для нескольких приложений.

Сервис "Пасспорт юзера" для нескольких приложений.

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 8 ноября 2016 г. 11:41

    Кто пользовался тем же хабром знают что такое ХабраID или как он там называется не помню.

    Кто-то реализовывал что-то подобное?

    То есть есть одна система авторизации, свой собственный oauth2 провайдер я так понимаю, мини приложение где буквально можно просто авторизоваться и выйти, а так же какие то нехитрые манипуляции типа контроль email'ов юзера или прочее, даже не ебу.

    Зачем это надо - есть например одна тематика и сайт на 2-3 языках, вот хочется чтобы юзер мог между сайтами при переходе не заполнять всю фигню, а просто использовать этот профиль, ну и ID чтобы не плодились и тп. То есть сайты работают по системе Remote Auth, а так же могут добавиться в эту сеть другие подпроекты в которых хотелось бы тоже поддержать авторизацию, то есть хочется сквозной профайл юзера через сеть сайтов, возможно 3rd party авторизация.

    пока писал понял что описал банального OAuth2 провайдера. Тогда второй вопрос - решения какие то кто-то знает под него адекватные?

    Сапожник без сапог
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 8 ноября 2016 г. 11:47, спустя 5 минут 37 секунд

    Даже уже и серверок нагуглил. Не зря говорят что правильно поставленый вопрос содержит 80% ответа :)

    Single Sign-On | The Gluu Server for SSO, WAM, & 2FA | Gluu [gluu.org]

    Сапожник без сапог
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 8 ноября 2016 г. 12:22, спустя 34 минуты 5 секунд

    @Crank, нет, мне надо сервер oauth, а не клиента

    Сапожник без сапог
  • Crank

    Сообщения: 542 Репутация: N Группа: Джедаи

    Spritz 8 ноября 2016 г. 12:26, спустя 3 минуты 54 секунды

    @phpdude, значит в глаза ебусь, глянул мельком запросы в доке и решил что сервер там тоже есть

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 8 ноября 2016 г. 12:40, спустя 14 минут 3 секунды

    @phpdude, значит в глаза ебусь, глянул мельком запросы в доке и решил что сервер там тоже есть

    @Crank, нет нету конечно :)

    Сапожник без сапог
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 8 ноября 2016 г. 19:27, спустя 6 часов 46 минут 47 секунд

    ory-am/hydra [github.com]

    Спустя 9 сек.

    вот еще чтото похожее на полноценное решение

    Сапожник без сапог
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 14 ноября 2016 г. 2:47, спустя 5 дней 7 часов 20 минут

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

    1. есть сервер (A) на котором хранятся учетки и он отвечает за вутентификацию
    2. при входе на других доменах (B) мы на самом деле отправляем пользователя логиниться на том сервере, а он нас отправляет назад на адрес типа /setcookie?cookie=abcd - какой-то хеш, ставим эту куку, типа rememberme

    При заходе на какой-то третий домен (C) для разлогиненых на страницу встраивается <script> по адресу A, ну типа <script src="A/is_authinticated?from=C">, сервер A же всегда знает - залогинен я или нет. И вот если я залогинен - то по этому адресу выдается document.location=c/setcookie?cookie=abcd

    При выходе - выходим с сервиса C и отправляем на A/logout.

    Ну тут еще куча всякой фигни типа csrf-токены и главное все правильно продумать, что б нигде не словить цикличных редиректов. Я их на яндексе, например с планшета/телефона частенько на них попадаю.

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

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 14 ноября 2016 г. 2:52, спустя 5 минут 7 секунд

    Абырвалг, 13 ноября 2016 г. 23:47

    есть сервер (A) на котором хранятся учетки и он отвечает за вутентификацию
    при входе на других доменах (B) мы на самом деле отправляем пользователя логиниться на том сервере, а он нас отправляет назад на адрес типа /setcookie?cookie=abcd - какой-то хеш, ставим эту куку, типа rememberme

    @Абырвалг, 1 - да, 2 - тупняк старый, тут правильнее просто точку А реализовывать как OAuth сервер (для проектов типа B) и клиент одновременно (для всяких фейсбуков и прочей хуеты чтобы юзера не грузить регистрациями), ну а B умеет только одну oauth - нашу и все.

    Я уже для себя все решил по этому поводу, интересны решения под oauth client/server. Есть решения под клиента, но блин не ебу чо с нагрузкой и тп, инетерсная задачка. Вполне возможно на django тупо пара апликух и ок, и еще непонятное какое API должно быть доступно на A, ведь будет центральный профиль + доп профили которые относятся только к проекту какому то например %) непонятно насколько глубоко должен быть центральный профиль интегрирован в проекты, хочется сделать так чтобы юзер имел возможность типа импортировать данные или сразу использовать %)

    В общем brain storm :)

    Спустя 79 сек.

    Абырвалг, 13 ноября 2016 г. 23:47

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

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

    Сапожник без сапог
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 14 ноября 2016 г. 3:01, спустя 8 минут 51 секунду

    нам oauth не совсем как бы подошел потому что мы втихую пользователя сами залогинивали, без всяких там вопросов - а хотите ли вы такому-то проекту передать свои данные

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 14 ноября 2016 г. 3:03, спустя 1 минуту 51 секунду

    Абырвалг, 14 ноября 2016 г. 0:01

    нам oauth не совсем как бы подошел потому что мы втихую пользователя сами залогинивали, без всяких там вопросов - а хотите ли вы такому-то проекту передать свои данные

    @Абырвалг, ну я думаю это поведение на своих клиент/сервере oauth я могу поменять чутка )))))) я к тому что сам протокол решает все описаные выше проблемы и в общем то для этого и создавался

    Сапожник без сапог
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 1 декабря 2016 г. 2:56, спустя 3 часа 48 минут 40 секунд

    На Laravel есть такое.

    https://laravel.com/docs/5.3/passport

    @tmaslo22, пхп не интересен в принципе, переболел им :)

    Интересны питон, Go и возможно NodeJS

    Сапожник без сапог
  • Julianna00

    Сообщения: 1 Репутация: N Группа: Кто попало

    Spritz 23 июня 2020 г. 19:07, спустя 1300 дней 16 часов 10 минут

Пожалуйста, авторизуйтесь, чтобы написать комментарий!