no-task: заменил basic auth на кастомную схему - #1
Conversation
|
|
||
| chain.doFilter(request, response); | ||
| } | ||
| chain.doFilter(request, response); |
There was a problem hiding this comment.
chain.doFilter(request, response); в случае успеха вызывается дважды, может быть источником трудноуловимых багов
| } catch (AuthenticationException var8) { | ||
| this.securityContextHolderStrategy.clearContext(); | ||
| this.logger.debug("Failed to process authentication request", var8); | ||
| response.sendError(HttpServletResponse.SC_FORBIDDEN); |
There was a problem hiding this comment.
вместо отправки ошибки лучше пользоваться AuthenticationEntryPoint, это более универсальный и гибкий способ
|
|
||
| import java.io.IOException; | ||
|
|
||
| public class RequestLoginPasswordFilter extends OncePerRequestFilter { |
There was a problem hiding this comment.
Вместо своего фильтра можно использовать AuthenticationFilter, а логику получения аутентификационных данных реализовать в классе, реализующем AuthenticationConverter
There was a problem hiding this comment.
о, спасибо за замечание)
There was a problem hiding this comment.
Честно говоря, попробовал - не получилось.
builder .addFilterAfter(requestJwtTokensFilter, ExceptionTranslationFilter.class) .addFilterAfter(authenticationFilter, ExceptionTranslationFilter.class)
менял местами эти две строчки (authenticationFilter - это созданный с кастомным конвертером) - все равно в дебаггере вижу что он пытается провести конвертацию через Jwt конвертер.
Плюс, конструктор принимающий менеджер аутентификации и конвертер не дает конфигурировать путь, по которому он должен отрабатывать. Короче какая-то беда. Хотя идея переиспользовать по максимуму спринговый функционал мне нравится.
| if (this.requestMatcher.matches(request)) { | ||
| try { | ||
| var isNative = checkNativeHeader(request); | ||
| if (!isNative) { |
There was a problem hiding this comment.
Не совсем понятно - а зачем?) Кто угодно может добавить заголовок X-native в запрос и всё
There was a problem hiding this comment.
для иллюстрации) можно добавить значение секретное например и его сверять)
2 participants
Решил попробовать изменить basic аутентификацию на "более привычную" через post запрос с jsonbody с минимальным конфигурированием. для обеспечения "правильности" клиентов предусмотрен специальный хедер, который будут отправлять только нативные клиенты, например.
насколько такой подход имеет право на жизнь?)