AccessDecisionManager 를 사용해서 Access Control , 예외처리를 하는 필터이다.
대부분의 경우 FilterChainProxy에 제일 마지막에 들어있다.
최종적으로 접근이 가능한지 확인을 한다.
public class FilterSecurityInterceptor extends AbstractSecurityInterceptor implements Filter {
부모클래스인 abstractSecuritInterceptor로 한번 들어가서 확인해보자.
확인해볼 메소드는 다음과 같다.
this. accessDecisionManager. decide(authenticated, object, attributes) ; 를 보면
accessDecisionManager는 AccessDecisionMangager객체의 변수명이고
decide 는 AccessDecisionMangager.class가 가지고있는 메서드 이름이다.
전달된 매개 변수에 대한 access control 결정을 확인한다.
매개 변수
throws
예제를 통해 한번 확인해보자
조건
디버깅 위치.
object -> url 매핑 주소
attributes -> List 형태의 조건 객체 배열
authenticated -> 로그인 안했으니 UsernamePassword어쩌고 저쩌고가 아닌 AnonymousAuthenticaionToken 확인
그리고 중요한것은 attributes 에 조건은 authenticated 이다.
어쨋든 우리는 authenticated 되지 않았으니
catch 부분으로 넘어간다.
AccessDeniedException 이 등장했다 어쨋든 Exception 됬다.
결국 handler를 통해서 formlogin() 페이지로 넘어오게 된다.
다른 테스트
2. 조건
/dashboard 접근 확인
authenticated 조건 확인
UsernamePasswordAuthenticationToken으로 접근한것 확인 ( anonymous 어쩌고 저쩌고 토근이 아님)
자 이번에는 catch 문에 걸리 않고 잘 넘어가야 하겠죠?
잘 넘어 가는 모습.
페이지도 잘 출력된다.
.
.
.
.
.
<중간정리>
어쨋든 인증은
SecurityContextHolder는 Authentication 객체를 저장하고 있다.
Authentication 은 AuthenticationManager를 통해서 인증하고
이를 SecurityContextHolder에 set해준다.
-->
UsernamePasswordAuthenticationFilter + SecurityContextPersistenceFilter 의 역할
그리고 이 필터들은 FilterChainProxy에 묶여있고 또한 FilterChainProxy가 필터에 분배하며
또는 FilterChainProxy 마저도 DelegationFilterProxy(자동으로 설정) 를 통해서 일을 전달 받았으며
인가는
AccessDecisionManager 가 사용되는데
AccessDecisionManager 는 여러개의 AccessDecisionVoter 를 가지고있다 어떤형태로? List<accessdecisionvoter<?>>
여기서도 또한 필터가 사용되는데 FilterSecurityInterceptor 필터가 사용되며
최종적인 인가정보를 확인하여 처리한다.
SpringSecurity [JWT 메소드 구경하기] (0) | 2022.07.06 |
---|---|
SpringSecurity [ExceptionTranslationFilter] (0) | 2022.07.06 |
SpringSecurity [AccessDecisionManager] (0) | 2022.07.04 |
SpringSecurity [DelegatingFliterProxy] (0) | 2022.06.30 |
SpringSecurity [FilterChainProxy] (0) | 2022.06.29 |
댓글 영역