Любое решение не будет дешёвым, просто потому что задача объёмная. Я бы остановился на отдельном беке аутентификации (oAuth сервере) + там запилил логику биллинга, кому давать, кому не давать + мб небольшую апишку на него. На остальных беках запилил oAuth клиент плюс интеграцию с auth что бы можно было в момент захода сходить на auth и проверить оплату к примеру
А как быть с авторизацией по сессии?
Я понял, вообщем буду думать Спасибо за советы и помощь
Так на здоровье. Зашёл например на foo, тебя кинуло на auth, ты ввёл свои данные и перекинуло на foo. Потом зашёл на bar, там тебя кинуло на auth, а на auth сессия не протухла и тебя сразу кинуло на bar
А как называется технология, которая используется в гугле/яндексе, Типа ЯндексПаспорт, авторизовался в нем и доступ к почте и т.п. уже есть. Вышел из паспорта - вылетел и из почты....
oauth 2.0 ))
Так вот сейчас пилю и не очень понимаю
Есть портал некий, они через нас будут авторизовывать юзеров. Но если у нас разлогинится - то у них не выйдет же...
В oAuth2 такого нет. Если условный акк facebook протухнет, то клиент узнает только когда попробует через него зайти. Если oAuth клиент-сервер свои, можно по шине пушнуть что протухло
Этого в спеке самого oAuth вроде бы нет. То уже сверху самим лепить
Есть два варианта: 1. Поднимаешь сокеты и их приложение должно обрабатывать это сообщение для разлогина; 2. При попытке запроса возвращать "не авторизован" и их приложение должно обрабатывать это. В идеале сделать оба варианта, т.к. запрос до сокета летит.
oauth это сервер авторизации. Всё остальное это плюшки, разарабываемые разработчиками.
Ну да
Да, можно. Но клиент должен подключаться к сокетам и реагировать на его сообщения.
Обсуждают сегодня