фильтр (для аутентификации по логину/паролю), а в каком случае свой эндпоинт в контроллере, если речь идёт об api приложении со stateless jwt токенами?
Если речь идёт о http basic аутентификации, то вижу логику в использовании фильтра (т.к. при каждом запросе надо смотреть именно по логину и паролю, независимо от эндпоинта), но вот в случае если у нас stateless jwt аутентификация, кажется, логичнее в эндпоинте контроллера выдать токен (проверив логин и пароль), а потом уже для токена фильтр сделать.
Но все же смущает, что в некоторых примерах вижу, что именно аутентификацию по логину паролю и выдачу токена пишут наследуясь фильтра от UsernamePasswordAuthenticationFilter.
Upd: нашел вопрос на https://stackoverflow.com/questions/51634553/why-the-authentication-should-be-implemented-in-a-filter-and-not-in-a-controller
если речь о JWT, то, насколько я знаю, в любом случаи нужно использовать фильтр, чтоб распарсить токен и на его основе наполнить SecurityContext ну и снова, если речь о JWT, то придется выставить ендпоинт для генерации токена, иначе как еще клиенту получить этот токен..
Обсуждают сегодня