Реестр сервисов нужен чтобы сопоставлять ip или имя-хоста с конкретным сервисом. Но если мы имеем возможность руками задавать имя виртуального хоста, то зачем нам реестр сервисов? Конкретный пример: пусть у нас есть старая версия сервиса v1 которая работает на хосте предыдущая-версия и новая версия v2 которая работает на хосте актуальная-версия. Пусть у нас появляется ещё более новая версия сервиса v3. Тогда мы просто выводим из эксплуатации хост предыдущая-версия. Хост актуальная-версия переименовываем в предыдущая-версия, а для новейшей версии сервиса v3 создаём новых хост по имени актуальная-версия. Всё. Никаких настроек маршрутизации не требуется.
Я не говорю что реестр сервисов - плохо. Наоборот, реестр сервисов -хорошо. Он решает свою задачу. Просто, его применение часто может быть избыточно.
> Ваш AuthService не удовлетворяет даже 5% от тех требований, которые предъявляются к реальным серверам авторизации. Согласен, но всё же замечу что свою функцию - быть единой точкой авторизации, он всё-таки выполняет. В большинстве случаев это единственное что требуется от сервиса авторизации. Можете ли вы сказать что-нибудь насчёт небезопасности или прямой уязвимости такого подхода? Замечу, что вопрос именно об уязвимости. Отсутствие дополнительной функциональности не является уязвимостью.
>появляются новые классы - неудивительно, фрэймворк развивается, появляются новые фичи .
Я сравниваю количество изменений (если хотите количество depricated) между различными версиями различных проектов и изменений в spring security от версии к версии видится на порядок больше. Возможно это субъективное впечатление.
Вероятно вам стоит вынести логику в отдельную БИБЛИОТЕКУ которую вы могли бы подключить к каждому из своих сервисов ресурсов для проверки и работы с авторизацией.
Там ещё и бэк всего с одним апи. Когда уже наконец авторам запретят обманывать наивных читателей?!
Реестр сервисов нужен чтобы сопоставлять ip или имя-хоста с конкретным сервисом. Но если мы имеем возможность руками задавать имя виртуального хоста, то зачем нам реестр сервисов?
Конкретный пример: пусть у нас есть старая версия сервиса v1 которая работает на хосте предыдущая-версия и новая версия v2 которая работает на хосте актуальная-версия.
Пусть у нас появляется ещё более новая версия сервиса v3. Тогда мы просто выводим из эксплуатации хост предыдущая-версия. Хост актуальная-версия переименовываем в предыдущая-версия, а для новейшей версии сервиса v3 создаём новых хост по имени актуальная-версия.
Всё. Никаких настроек маршрутизации не требуется.
Я не говорю что реестр сервисов - плохо. Наоборот, реестр сервисов -хорошо. Он решает свою задачу. Просто, его применение часто может быть избыточно.
> Ваш AuthService не удовлетворяет даже 5% от тех требований, которые предъявляются к реальным серверам авторизации.
Согласен, но всё же замечу что свою функцию - быть единой точкой авторизации, он всё-таки выполняет. В большинстве случаев это единственное что требуется от сервиса авторизации.
Можете ли вы сказать что-нибудь насчёт небезопасности или прямой уязвимости такого подхода? Замечу, что вопрос именно об уязвимости. Отсутствие дополнительной функциональности не является уязвимостью.
>появляются новые классы - неудивительно, фрэймворк развивается, появляются новые фичи .
Я сравниваю количество изменений (если хотите количество depricated) между различными версиями различных проектов и изменений в spring security от версии к версии видится на порядок больше. Возможно это субъективное впечатление.
Вероятно вам стоит вынести логику в отдельную БИБЛИОТЕКУ которую вы могли бы подключить к каждому из своих сервисов ресурсов для проверки и работы с авторизацией.