На счет отсутствия выгоды в задачах, занимающих процессор, в спеке так и сказано что виртуал треды для этого и не предназначены, поэтому логично что тут выгоды то и нет, ее неоткуда взять.
В Вашем примере логика авторизации размазана на несколько сервисов (gateway, resource). Обычно, такие вещи делают только в одном месте, а именно на стороне шлюза. Бизнесовые сервисы уже стоят за шлюзом и из большого интернета к ним не попадешь, поэтому там не так важно проверять авторизацию (разве что передать токен для вытягивания из него пользователя, но без проверки подписи). Непосредственно проверку авторизацию и редирект на логин логично сделать только на стороне шлюза.
И еще поделюсь личным опытом, использование конфиг сервера не очень удобно. Были проблемы при сборке образов сервисов на момент когда конфиг сервер еще не поднялся (docker compose ). Да и конфиги лежат, совсем не рядом с сервисом, что добавляло неудобство их просмотров. В нашем случае конфиг сервер добавлял только ограничения в нашу архитектуру и не приносил удобств
Здравствуйте, согласен, решение с передачей refresh токена не лучшее. Но смею предположить, что вы недостаточно внимательно прочли вывод статьи. В нем я черным по белому поясняю, что суть статьи не в Best Practice применения OAuth2 протокола, а в том как работают фильтры Spring Security и в каком порядке они обрабатывают запрос. Основной упор заключается именно в этом, а не в том что мы передаем Refresh токен и используем deptecated подходы. Keycloak тут просто послужил причиной разобраться в теме фильтров, поэтому на его примере и написана статья. Что касается вопросов применения OAuth2, еще раз соглашусь, в моем примере приведен не самый лучший вариант его использования.
Может я не понимаю, а чем не подходит вариант типа
@Configuration
public class MyConfig { Bean
public MyCystomBean initMyCustomBean() {
return new MyCustomBean();
}
}
Потом в любых других бинах можно внедрять его. Реализация будет подставлена именно эта. В 5 спринге мне так удавалось делать. Если я в чем то не прав, объясните плиз)
На счет отсутствия выгоды в задачах, занимающих процессор, в спеке так и сказано что виртуал треды для этого и не предназначены, поэтому логично что тут выгоды то и нет, ее неоткуда взять.
https://docs.oracle.com/en/java/javase/20/core/virtual-threads.html#GUID-15BDB995-028A-45A7-B6E2-9BA15C2E0501
В Вашем примере логика авторизации размазана на несколько сервисов (gateway, resource). Обычно, такие вещи делают только в одном месте, а именно на стороне шлюза. Бизнесовые сервисы уже стоят за шлюзом и из большого интернета к ним не попадешь, поэтому там не так важно проверять авторизацию (разве что передать токен для вытягивания из него пользователя, но без проверки подписи). Непосредственно проверку авторизацию и редирект на логин логично сделать только на стороне шлюза.
И еще поделюсь личным опытом, использование конфиг сервера не очень удобно. Были проблемы при сборке образов сервисов на момент когда конфиг сервер еще не поднялся (docker compose ). Да и конфиги лежат, совсем не рядом с сервисом, что добавляло неудобство их просмотров. В нашем случае конфиг сервер добавлял только ограничения в нашу архитектуру и не приносил удобств
Подумаем над этим, спасибо за комментарий!
первое решение у нас и было реализовано, решили прокачать более гибко, спасибо
Здравствуйте, согласен, решение с передачей refresh токена не лучшее. Но смею предположить, что вы недостаточно внимательно прочли вывод статьи. В нем я черным по белому поясняю, что суть статьи не в Best Practice применения OAuth2 протокола, а в том как работают фильтры Spring Security и в каком порядке они обрабатывают запрос. Основной упор заключается именно в этом, а не в том что мы передаем Refresh токен и используем deptecated подходы. Keycloak тут просто послужил причиной разобраться в теме фильтров, поэтому на его примере и написана статья. Что касается вопросов применения OAuth2, еще раз соглашусь, в моем примере приведен не самый лучший вариант его использования.
Спасибо за Ваш комментарий.
@Configuration
public class MyConfig {
Bean
public MyCystomBean initMyCustomBean() {
return new MyCustomBean();
}
}
Потом в любых других бинах можно внедрять его. Реализация будет подставлена именно эта. В 5 спринге мне так удавалось делать. Если я в чем то не прав, объясните плиз)