Сергей: используйте патерны. Наример централизуйте систему для получения фона. А после просто вызывайте функцию с получением фона. Прячьте логику за интерфейсом.
Станислав Макаров: я подразумеваю OpenID Connect. И да, видимо он решит мою задачу. Пока изучаю протокол и реализации. Но чем дальше в лес, тем волки страшнее.
Кстати, я тут набросал свой велосипед с единым аккаунтом: Нагрузка на REST API в описанной реализации?
Имеет место быть такая архитектура?
Defman21: смотрел, то что нужно. Но фраемворки работают на сессиях и сделаны под WEB. А мне для API. Реализовывать свой CAS... вот и придумал систему, описанную в вопросе.
Defman21: думаю я остановлюсь на варианте попроще.
Как считаете, то что каждый запрос к API Проекта будет делать запрос к API авторизации не сильно нагрузит сервер?
Сегодня сделал тестовую систему, на холодную 300ms было, дальше в районе 100ms
xfg: банить - нет. Я уже понял что это бесмвсленно.
Цель такая: скажем я выпустил новый клиент на ios, а старый хочу не обрабатывать. Просто делаю неактивным клиентское приложение у себя на сервере, и ответы от него не приходят.
Вопрос не в безопасности, а в удобстве. Обычный пользователь откроет приложение и увидит мол "клиент больше не активен, удаляй". Утрирую, но идея должна быть понятна
Казалось что в этом есть необходимость. Получается, что даже если я хочу работать только со "своими" клиентами - подписывать запрос не имеет смысла. Хотя изнутри что-то гложит)
Спасибо за ответ, это решение одназначно.
Дополнительный вопрос: если я захочу в один момент отключить запросы от приложения, как это лучше организовать? К примеру есть клиенты на android и ios, появилась необходимость отключить приложение на ios.
Станислав Макаров: тут нюанс в том, что будет запрос у пользователя разрешение. А нужно обычная доверенная авторизация. Только хранить все в единой точке.
Что скажешь насчет обычного jwt, и передачи токена проекту?
