⠀
Роман Нагаев
это можно настраивать, но получается сложно
Есть материалы какие-то почитать?
Size: a a a
2020 February 01
LM
Обрати внимание на hibernate search. Мне кажется ты решаешь задачу в лоб
РН
Есть материалы какие-то почитать?
V@
Есть материалы какие-то почитать?
Вот этот чувак майнтейнит гибернейт и активно пишет блог. https://vladmihalcea.com/
V@
Значит надо их добавить
почитал я про энтрипоинты эти https://www.baeldung.com/spring-security-multiple-entry-points - не про мой кейс они. мне для АПИ нужно отдавать 403, если не авторизован.
V
почитал я про энтрипоинты эти https://www.baeldung.com/spring-security-multiple-entry-points - не про мой кейс они. мне для АПИ нужно отдавать 403, если не авторизован.
Both of the above configurations will redirect to a /403 URL if a user without the appropriate role attempts to access a protected URL.
V@
Vadim
Both of the above configurations will redirect to a /403 URL if a user without the appropriate role attempts to access a protected URL.
это не то, что мне нужно. у меня спринг-фильтр для авторизации по JWT. который (в случаях проблемы авторизации) сбрасывает контекст спринг-секурити (clearContext). И далее с помощью
.formLogin().loginPage("/auth/signin") идет редирект на страницу авторизации. И это нормальное поведение. Если пользователь открывает хомяк админки незалогиненным, то его редиректит на авторизацию. Но если он сидит в админке (ReactJS) и JWT истекает, то его разлогинивает, а на ajax запрос возвращается тот же самый редирект на /auth/sighin тем же самым механизмом. Но мне не надо редиректа на ajax. Мне бы 403 ошибочку.V
Странная ситуация. Должны быть рефреш токены, которые обновляют аксесс токены. Может тут проблема в том, как организована jwt аутентификация?
V
Ну и в любом случае, можно попробовать в секюрите конфиги кастомно настроить поведение для урлов, которые начинаются с "/api/**", если только фильтр раньше запрос не перехватит. Надо пробовать.
V@
Vadim
Странная ситуация. Должны быть рефреш токены, которые обновляют аксесс токены. Может тут проблема в том, как организована jwt аутентификация?
рефреш-токен это уже в следующей поставке надо-ть :)
V@
Vadim
Ну и в любом случае, можно попробовать в секюрите конфиги кастомно настроить поведение для урлов, которые начинаются с "/api/**", если только фильтр раньше запрос не перехватит. Надо пробовать.
я попробовал интерсептор подцепить. только вот он в postHandle не доходит, когда jwt-фильтр очистил контекст секурити
V@
о, есть какой-то CustomAuthenticationFailureHandler https://www.baeldung.com/spring-security-custom-authentication-failure-handler - буду пробовать
V@
не... это не то.
V@
Vadim в общем, прочитав https://www.codesandnotes.be/2014/10/31/restful-authentication-using-spring-security-on-spring-boot-and-jquery-as-a-web-client/ , я понял, что эти энтрипоинты вроде бы мне подохят. Даже запилил вот пробу. Но оно все равно мне редирект делает на ajax.
V@
отладчиком туда даже не заходит.
V
Фильтр может раньше отрабатывает
RS
Vadim в общем, прочитав https://www.codesandnotes.be/2014/10/31/restful-authentication-using-spring-security-on-spring-boot-and-jquery-as-a-web-client/ , я понял, что эти энтрипоинты вроде бы мне подохят. Даже запилил вот пробу. Но оно все равно мне редирект делает на ajax.
попробуйте вместо
new NegatedRequestMatcher(первый матчер) - чтобы точно исключить /api из матчера. хотя это конечно пальцем в небо.
лучше всего включить уровень ДЕБАГ для логгера org.springframework.security (а можно и для org.springframework - не помешает). Например, DelegatingAuthenticationEntryPoint пишет в лог
и сразу видно, какие матчеры пытались использоваться и какой в итоге "прокнул". а уже дальше можно разбираться, почему.
/** во втором матчере передатьnew NegatedRequestMatcher(первый матчер) - чтобы точно исключить /api из матчера. хотя это конечно пальцем в небо.
лучше всего включить уровень ДЕБАГ для логгера org.springframework.security (а можно и для org.springframework - не помешает). Например, DelegatingAuthenticationEntryPoint пишет в лог
logger.debug("Trying to match using " + requestMatcher);
...
logger.debug("Match found! Executing " + entryPoint);и сразу видно, какие матчеры пытались использоваться и какой в итоге "прокнул". а уже дальше можно разбираться, почему.
V@
Vadim
Фильтр может раньше отрабатывает
да филтр никуда не редиректит
RS
а вообще-то погодите-ка. вы же говорите. что хотите обрабатывать не ситуацию, когда access denied, а ситуацию, когда токен протух, т.е. пользователь не известен. Тогда это defaultAuthenticationEntryPointFor, а не defaultAccessDeniedHandlerFor.
V
Ну и паттерн у тебя "/api**", а не “/api/**“