Spring HandleMethodArgumentResolver로 반복적인 Session 연산 처리

프로젝트를 진행하며 Spring Security를 사용하고 있어 Controller나 Service layer에서 별도로 사용자 인증, 인가 여부에 대해 하드 코딩하지 않아도 돼서 각각의 layer의 역할이 늘어나는 일을 막을 수 있다.

만약 별도로 login, logout을 구현해서 사용했더라면 추후 인증, 인가 방식에 변동이나 추가가 있을 경우 시스템을 확장 시키는게 아니라 변화 시켜야 하기 때문에 OCP에 반한다고 생각해서 추상화가 잘 되어 있는 Spring Security를 사용하게 되었는데 인증과 인가를 해결하더라도 컨트롤러에서 사용자 세션의 정보를 가져오는 부분에서는 Controller나 Service Layer에 녹아들 수 밖에 없었다.

물론 Spring Security는 어느 Layer에서든 Spring Security Context에서 사용자의 세션을 가져 올 수 있어 HttpSession을 통해 사용자의 세션 정보를 가져오는 것 보다는 간결하지만 그래도 반복적인 로직이 메서드마다 존재하는건 너무 신경이 쓰여 Spring의 HandleMethodArgumentResolver를 사용해 Security에서 Session 정보를 받아 별도로 넣어주는 방식으로 리팩토링했습니다.

우선 ThreadLocal한 Spring Security에서 사용자 Session을 불러오는 것을 먼저 보면

controller에서 인증 객체 가져오기 

이런식으로 별도의 객체 선언 없이 바로 SecurityContextHolder로 SecurityContext를 불러와서 사용자 인증 객체를 가져올 수 있고

같은 방식으로 Service Layer에서도 인증 객체를 불러올 수 있다.

하지만 이런 방식으로 Controller나 Service에서 인증 객체로 사용자의 정보를 가져오는 방식은 반복적인 작업일뿐 아니라
메서드가 하는 일이 한 가지가 아니라 2개가 되어 버린다.

그래서 별도의 애너테이션을 사용해서 사용자 세션의 UserPrincipal 객체를 요청 실행시에 HandleMethodArgumentResolver로 넣어주는 방식으로 리팩토링 했습니다.

Runtime동안 동작하기위한 애너테이션을 선언하고

이 애너테이션을 붙이 인자에 대해 처리해줄 HandleMethodArgumentResolver를 상속받은 객체를 생성합니다.

내부 메서드를 타고 들어가서 설명을 읽어보면 supportParameter함수가 true를 반환해야 resolveArgument가 동작한다고 합니다.

그래서 supportParameter의 true 반환 조건으로 parameter의 애너테이션인 LoginUser.class인지 확인하고 동시에 인증 객체가 AbstractAuthenticationToken 타입인지 확인하는 조건을 넣어줍니다.

이 후 true가 반환된다면 resolveArgument 메서드가 실행되어 인증 객체를 받아 넘겨주게 됩니다.

그리고 이 resolve를 WebMvcConfig에 ArgumentResolver에 추가해주면 위에서 생선한 Resolver가 추가되어 동작하게 됩니다.

디버깅을 통해 사용자 인증 객체로 UserPrincipal을 HandleMethodArgumentResolver가 추가 해주는 것을 확인할 수 있습니다.

이런식으로 반복된 세션 작업을 간단하게 처리되도록 리팩터링 할 수 있었습니다.

그럼 20000