스프링 인터셉터
스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다.
서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다.
둘다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 그리고 사용방법이 다르다
인터셉터의 흐름
스프링 인터셉터는 디스패처 서블릿과 컨트롤러 사이에서 컨트롤러 호출 직전에 호출 된다.
스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패처 서블릿 이후에 등장하게 된다.
(스프링 MVC의 시작점이 디스패처 서블릿이라고 생각해보면 이해가 될 것이다.)
스프링 인터셉터에도 URL 패턴을 적용할 수 있는데, 서블릿 URL 패턴과는 다르고, 매우 정밀하게 설정할 수 있다.
스프링 인터셉터 제한
인터셉터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝을 낼 수도 있다.
그래서 로그인 여부를 체크하기에 딱 좋다.
스프링 인터셉터 체인
스프링 인터셉터는 체인으로 구성되는데, 중간에 인터셉터를 자유롭게 추가할 수 있다.
예를 들어서 로그를 남기는 인터셉터를 먼저 적용하고, 그 다음에 로그인 여부를 체크하는 인터셉터를 만들 수 있다.
지금까지 내용을 보면 서블릿 필터와 호출 되는 순서만 다르고, 제공하는 기능은 비슷해 보인다.
앞으로 설명하겠지만, 스프링 인터셉터는 서블릿 필터보다 편리하고, 더 정교하고 다양한 기능을 지원한다.
스프링 인터셉터 인터페이스
스프링의 인터셉터를 사용하려면 HandlerInterceptor 인터페이스를 구현하면 된다.
public interface HandlerInterceptor {
default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
}
default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable ModelAndView modelAndView) throws Exception {
}
default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) throws Exception {
}
}
서블릿 필터의 경우 단순하게 doFilter() 하나만 제공된다. (필터 관련 메소드는)
인터셉터는 컨트롤러 호출 전( preHandle ), 호출 후( postHandle ), 요청 완료 이후( afterCompletion )와 같이
단계적으로 잘 세분화 되어 있다.
서블릿 필터의 경우 단순히 request , response 만 제공했지만,
인터셉터는 어떤 컨트롤러( handler )가 호출되는지 호출 정보도 받을 수 있다.
그리고 어떤 modelAndView 가 반환되는지 응답 정보도 받을 수 있다.
스프링 인터셉터 호출 흐름
정상 흐름일 경우
preHandle
컨트롤러 호출 전에 호출된다. (더 정확히는 핸들러 어댑터 호출 전에 호출된다.)
preHandle의 응답값이 true 이면 다음으로 진행하고, false이면 더는 진행하지 않는다.
false 인 경우 나머지 인터셉터는 물론이고, 핸들러 어댑터도 호출되지 않는다. 그림에서 1번에서 끝이 나버린다
preHandle의 응답값이 true 이면 다음 인터셉터를 호출하고, 다음 인터셉터가 없다면 핸들러 어댑터를 호출한다.
( preHandle에서 조건에 맞는지 체크하는 느낌, 현재 인터셉터의 조건에 맞는다면 다음 인터셉터의 preHandle을 진행한다. 그렇게 모든 인터셉터를 통과한다면 핸들러 어댑터를 호출하고, 정상진행된다.) (필터처럼)
postHandle
컨트롤러 호출 후에 호출된다. (더 정확히는 핸들러 어댑터 호출 후에 호출된다. 핸들러 어댑터 호출이 되면 해당 핸들러의 메소드가 호출되니까) 그래서 컨트롤러(핸들러)가 동작이 끝나고 ModelAndView를 반환할텐데 postHandle는 파라미터로 ModelAndView를 받을 수 있다. (ModelAndView를 반환한다면 있고, 없으면 null (API서버같은경우))
afterCompletion
뷰가 렌더링 된 이후에 호출된다 (API서버라면 응답이 나갈때?)
스프링 인터셉터 예외 상황
예외가 발생시 ( 진행과정중 3번인 핸들러(컨트롤러)에서 예외가 발생한 상황)
preHandle
컨트롤러 호출 전에 호출된다.
postHandle
컨트롤러에서 예외가 발생하면 postHandle 은 호출되지 않는다.
afterCompletion
afterCompletion 은 항상 호출된다.
이 경우 예외( Exception ex )를 파라미터로 받아서 어떤 예외가 발생했는지 로그로 출력할 수 있다.
정상진행인 경우에는 Exception ex에는 null이 들어간다 (@Nullable)
afterCompletion은 예외가 발생해도 호출된다
예외가 발생하면 postHandle() 는 호출되지 않으므로
예외와 무관하게 공통 처리를 하려면 afterCompletion() 을 사용해야 한다.
예외가 발생하면 afterCompletion() 에 예외 정보( ex )를 포함해서 호출된다.
정리
인터셉터는 스프링 MVC 구조에 특화된 필터 기능을 제공한다고 이해하면 된다.
스프링 MVC를 사용하고, 특별히 필터를 꼭 사용해야 하는 상황이 아니라면
인터셉터를 사용하는 것이 더 편리하다.
스프링 인터셉터 - 요청 로그 (request Logging)
이전게시글에서 서블릿 필터로 request로그를 찍어보는 필터를 만들어본적이 있다.
그것을 똑같이 스프링 인터셉터를 이용해서 만들어보자.
Loginterceptor
@Slf4j
public class Loginterceptor implements HandlerInterceptor {
public static final String LOG_ID = "logId";
//HandlerInterceptor안의 메소드들은 다 default로 되어있어서 직접 오버라이드 해준다.
//오버라이드 할 메소드들을 가져오는 단축키는 Ctrl + O이다.
//여기다가 String uuid = UUID.randomUUID().toString(); 는 못한다. 인터셉터는 싱글톤으로 관리되는데 하나의 쓰레드가 사용중이다가 다른쓰레드가 접근하면 값이 바뀌어 버린다고 한다.
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String requestURI = request.getRequestURI();
String uuid = UUID.randomUUID().toString();
//afterCompletion에서도 uuid를 가지고있어야 로그를 찍을것이다.
request.setAttribute(LOG_ID, uuid); //request.setAttribute를 이용해서 값을 담는다. 초창기에 HttpServletRequest를 모델로 썼을때 사용하던 방법이다.
if (handler instanceof HandlerMethod) {
// handler라는 이름으로 넘어온 오브젝트가 HandlerMethod의 객체인지 체크
// @Controller, @RequestMapping을 사용해서 핸들러매핑을 RequestMappingHandlerMapping로 사용하게 되면 이 경우에는 핸들러 정보로 HandlerMethod가 넘어온다.
HandlerMethod hm = (HandlerMethod) handler; //HandlerMethod에는 메소드의 모든 정보(Bean에 대한 정보 포함)가 들어있다.
}
log.info("REQUEST [{}] [{}] [{}]", uuid, requestURI, handler);
return true; //true가 되면 다음 인터셉터로 넘어가는데 다음 인터셉터가 없다면 핸들러(컨트롤러)가 실행된다.
}
@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
//postHandle()은 컨트롤러의 동작이 끝나고 실행
log.info("postHandle [{}] ",modelAndView);
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
//afterCompletion()는 뷰 렌더링까지 마치고 실행된다.
String requestURI = request.getRequestURI();
String uuid =(String) request.getAttribute(LOG_ID);
log.info("RESPONSE [{}] [{}] [{}]", uuid, requestURI, handler);
if (ex != null) { //예외가 터진경우라면
log.error("afterCompletion error!!",ex);
}
}
}
request.setAttribute(LOG_ID, uuid);
서블릿 필터의 경우 지역변수로 해결이 가능하지만, 스프링 인터셉터는 호출 시점이 완전히 분리되어 있다.
따라서 preHandle 에서 지정한 값을 postHandle , afterCompletion 에서 함께 사용하려면 어딘가에 담아두어야 한다. LogInterceptor 도 싱글톤 처럼 사용되기 때문에 맴버변수를 사용하면 위험하다. 따라서 request 에 담아두었다.
이 값은 afterCompletion 에서 request.getAttribute(LOG_ID) 로 찾아서 사용한다.
true 면 정상 호출이다. 다음 인터셉터나 컨트롤러가 호출된다
if (handler instanceof HandlerMethod) {
// handler라는 이름으로 넘어온 핸들러정보가 HandlerMethod의 객체인지 체크
// @Controller, @RequestMapping을 사용해서 핸들러매핑을 RequestMappingHandlerMapping로 사용하게 되면 이 경우에는 핸들러 정보로 HandlerMethod가 넘어온다.
HandlerMethod hm = (HandlerMethod) handler; //HandlerMethod에는 메소드의 모든 정보(Bean에 대한 정보 포함)가 들어있다.
}
핸들러 정보는 어떤 핸들러 매핑을 사용하는가에 따라 달라진다. 스프링을 사용하면 일반적으로 @Controller , @RequestMapping 을 활용한 핸들러 매핑을 사용하는데, 이 경우 핸들러 정보로 HandlerMethod 가 넘어온다.
ResourceHttpRequestHandler
@Controller 가 아니라 /resources/static 와 같은 정적 리소스가 호출 되는 경우
ResourceHttpRequestHandler 가 핸들러 정보로 넘어오기 때문에 타입에 따라서 처리가 필요하다
(대부분은 어노테이션컨트롤러이기 때문에 HandlerMethod라고 보면된다.)
HandlerMethod 란?
HandlerMethod는 @RequestMapping과 그 하위 어노테이션(@GetMapping, @PostMapping 등)이 붙은 메소드의 정보를 추상화한 객체이다. HandlerMethod는 그 자체가 실행가능한 객체가 아니라 메소드를 실행하기 위해 필요한 참저정보를 담고 있는 객체로써 다음과 같은 정보들을 가지고 있다.
- 빈 객체
- 메소드 메타정보
- 메소드 파라미터 메타정보
- 메소드 어노테이션 메타정보
- 메소드 리턴 값 메타정보
스프링 MVC 동작방식을 다시한번 본다( 어노테이션 컨트롤러 방식일때)
https://keeeeeepgoing.tistory.com/166
스프링 MVC는 어플리케이션 로딩 시점에
@Controller가 붙어있는 모든 클래스를 찾아서 그 안에 @RequestMapping의 메소드를
HandlerMethod로 변환해서 RequestMappingHandlerMapping에 보관하고 있는다.
(변환도RequestMappingHandlerMapping가 한다)
http 요청으로 url호출이 들어오면 RequestMappingHandlerMapping에서
해당 url패턴과 매핑되어있는 메소드정보를 가지고있는 HandlerMethod를 반환해준다.
(그이후 그 메소드의 정보가 담긴 HandlerMethod를 가지고
HandlerMethod안에있는 컨트롤러의 정보를 가지고 어댑터를 찾는것이다.)
@Controller, @RequestMapping을 사용해서 핸들러매핑을 RequestMappingHandlerMapping로
사용하게 되면 이 경우에는 핸들러 정보로 HandlerMethod가 넘어온다.
그러므로 http요청이 오고 preHandle이 호출될때 http요청에 맞는 HandlerMethod를 받을 수 있는것이다.
(HandlerMethod는 어플리케이션이 실행될때 준비되니까)
postHandle() , afterCompletion()
종료 로그를 postHandle 이 아니라 afterCompletion 에서 실행한 이유는,
예외가 발생한 경우 postHandle 가 호출되지 않기 때문이다.
afterCompletion 은 예외가 발생해도 호출 되는 것을 보장한다.
인터셉터 등록
WebConfig
@Configuration
public class WebConfig implements WebMvcConfigurer {
// 인터셉터 등록은 클래스에 implements WebMvcConfigurer 추가해주고
// addInterceptors()를 오버라이드 해야한다.
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new Loginterceptor())
.order(1) //인터셉터 순서
.addPathPatterns("/**") //인터셉터가 실행될 패턴정보 , 서블릿 URL과 다르다!
.excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터가 제외되는 url
}
// 직접 만든 필터를 등록해준다 자동 빈등록을 해주지않는 이유는 LogFilter 객체를 만들어서 스프링빈에 등록하려는게 아니고
// FilterRegistrationBean객체를 logFilter라는 스프링빈이름으로 등록하려고 하기 떄문인것같다.
// 스프링컨테이너에는 각 필터별 들이 스프링빈이름은 필터이름으로 가지고 , 스프링빈안에 빈객체는 FilterRegistrationBean를 가지며 그안에 필터객체,필터정보가 들어있는것이다.
@Bean
public FilterRegistrationBean logFilter() {
FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>(); //필터 등록용 빈을 만든다.
filterRegistrationBean.setFilter(new LogFilter()); // 내가만든 필터를 넣어주고
filterRegistrationBean.setOrder(1); // 필터의 순서도 넣어준다.
filterRegistrationBean.addUrlPatterns("/*"); // 어떤 url패턴에 적용할것인지 설정, /*는 모든 url를 의미한다.
return filterRegistrationBean;
}
//로그인체크 필터 등록
@Bean
public FilterRegistrationBean loginCheckFilter() {
FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
filterRegistrationBean.setFilter(new LoginCheckFilter());
filterRegistrationBean.setOrder(2);
filterRegistrationBean.addUrlPatterns("/*"); //어차피 화이티리스트를 넣어놨기때문에 모든 url에 적용해도 알아서 걸러진다.
return filterRegistrationBean;
}
}
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new Loginterceptor())
.order(1) //인터셉터 순서
.addPathPatterns("/**") //인터셉터를 적용할 패턴정보 , 서블릿 URL과 다르다!
.excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터가 제외되는 url
}
WebMvcConfigurer 가 제공하는 addInterceptors() 를 오버라이드해서 인터셉터를 등록할 수 있다.
( Class에서 WebMvcConfigurer를 implements해야하고 addInterceptors()를 오버라이드 해야하므로
따로 설정파일을 만들어서 인터셉터를 등록하는게 깔끔하다. 그래서 그안에서 인터셉터들을 등록하면 코드가 깔끔할것이다.) ( + 필터보다 인터셉터를 더 많이 사용한다.)
order()로 인터셉터의 호출 순서를 지정한다. 낮을 수록 먼저 호출된다.
addPathPatterns("/**") : 인터셉터를 적용할 URL 패턴을 지정한다.
(서블릿url 패턴이 아닌 스프링url패턴(PathPattern)이다 )
excludePathPatterns("/css/**", "/*.ico", "/error") : 인터셉터에서 제외할 패턴을 지정한다
(서블릿url 패턴이 아닌 스프링url패턴(PathPattern)이다 )
필터와 비교해보면 인터셉터는 addPathPatterns , excludePathPatterns 로 매우 정밀하게 URL 패턴을 지정할 수 있다
인터셉터를 스프링빈으로 등록하고 싶다면?
내가 만든 인터셉터를 스프링빈으로 등록해도 된다. @Component 추가하고, 원하는 의존관계 생성자주입으로 주입받고
인터셉터 등록할때 WebConfig에서도 내가만든 인터셉터를 주입받은 후
registry.addInterceptor(loginterceptor)
이런식으로 주입받은 객체를 넣어주면 될것이다.
실행 로그
localhost:8080로 http요청했을때 로그 ("/")
순서를 보면
로그필터 -> 로그인필터 try부분 -> 로그인터셉터prehandle() -> posthandle()->aftercompletion() -> 로그인필터 finally부분 -> 로그필터
이 순서대로다.
이렇게 진행되기 때문
postHandle가 받아온 ModelAndView내용도 확인할 수 있다.!
그리고 preHandle() , postHandle() , afterCompletion()의 파라미터인
Obejct handler
즉 HandlerMethod를 확인할 수 있다.
HandlerMethod의 toString덕에 저렇게 보이는것이다.
스프링의 URL 경로 (PathPattern)
위에서 인터셉터를 등록할때
.addPathPatterns("/**") //인터셉터를 적용할 패턴정보 , 서블릿 URL과 다르다!
.excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터가 제외되는 url
처럼 스프링이 제공하는 URL 경로는 서블릿 기술이 제공하는 URL 경로와 완전히 다르다.
더욱 자세하고, 세밀하게 설정할 수 있다.
문서를 참고하자.
스프링 인터셉터 - 인증 체크
서블릿 필터에서 사용했던 인증 체크 기능을 스프링 인터셉터로 개발해보자
@Slf4j
public class LoginCheckInterceptor implements HandlerInterceptor {
//로그인 체크는 postHandle,afterCompletion이 필요없다.
// postHandle은 컨트롤러가 동작 다 한뒤에 호출되는 메소드이고 , afterCompletion는 뷰까지 렌더링 되고 난뒤에 호출되니까.
// 핸들러메소드가 실행되기전인 preHandle에서 로그인체크처리를 하는것이 맞다.
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
Object handler) throws Exception {
String requestURI = request.getRequestURI();
log.info("인증 체크 인터셉터 실행 {} ", requestURI);
HttpSession session = request.getSession();
if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
log.info("미인증 사용자 요청");
//로그인으로 리다이렉트
response.sendRedirect("/login?redirectURL=" + requestURI);
return false; //리턴이 false이면 더이상 진행하지않는다 ( 컨트롤러(핸들러)호출 하지않는다.)
}
//인터셉터 통과
return true; // true이면 다음 인터셉터로 이동, 인터셉터가 없을시 컨트롤러 호출
}
}
서블릿 필터와 비교해서 코드가 매우 간결하다.
인증이라는 것은 컨트롤러 호출 전에만 호출되면 된다. 따라서 preHandle 만 구현하면 된다.
서블릿 필터를 만들때와 다르게 코드 내부에 uri를 검사하는 부분이 없다.
스프링 인터셉터는 인터셉터를 등록할때 인터셉터를 적용할 uri를 자세하게 지정하므로 코드내부에는 없다.
인터셉터 등록
@Configuration
public class WebConfig implements WebMvcConfigurer {
// 인터셉터 등록은 클래스에 implements WebMvcConfigurer 추가해주고
// addInterceptors()를 오버라이드 해야한다.
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new Loginterceptor())
.order(1) //인터셉터 순서
.addPathPatterns("/**") //인터셉터를 적용할 패턴정보 , 서블릿 URL과 다르다!
.excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터가 제외되는 url
//서블릿 필터는 추가 필터를 등록하려면 스프링빈으로 또 만들어줘야하지만
//스프링 인턴셉터는 InterceptorRegistry에 새로운 인터셉터를 추가해주기만 하면된다.
registry.addInterceptor(new LoginCheckInterceptor())
.order(2)
.addPathPatterns("/**") // 모든 경로에 대해서 로그인체크를한다.
.excludePathPatterns("/", "/members/add", "/login", "/logout", "/css/**", "/*.ico",
"/error"); //해당 url은 인터셉터 적용 제외힌다.
}
}
//서블릿 필터는 추가 필터를 등록하려면 스프링빈으로 또 만들어줘야하지만
//스프링 인턴셉터는 InterceptorRegistry에 새로운 인터셉터를 추가해주기만 하면된다.
인터셉터를 적용하거나 하지 않을 부분은 addPathPatterns 와 excludePathPatterns 에 작성하면 된다.
기본적으로 모든 경로에 해당 인터셉터를 적용하되 ( /** ),
홈( / ), 회원가입( /members/add ), 로그인( /login ), 리소스 조회( /css/** ), 오류( /error )와 같은 부분은
로그인 체크 인터셉터를 적용하지 않는다.
서블릿 필터와 비교해보면 매우 편리한 것을 알 수 있다.
정리
서블릿 필터와 스프링 인터셉터는 웹과 관련된 공통 관심사를 해결하기 위한 기술이다.
서블릿 필터와 비교해서 스프링 인터셉터가 개발자 입장에서 훨씬 편리하다는 것을 코드로 이해했을 것이다.
특별한 문제가 없다면 인터셉터를 사용하는 것이 좋다.
ArgumentResolver 활용
spring mvc1편에서 ArgumentResolver를 학습했었다.
https://keeeeeepgoing.tistory.com/183
이번 시간에는 해당 기능을 사용해서 로그인 회원을 조금 편리하게 찾아보자.
어노테이션을 만들고 만든 어노테이션이 붙어있는 파라미터에 대한 ArgumentResolver도 만들어서 편하게 코드를 짠다.
HomeController - 추가
@GetMapping("/")
public String homeLoginV3ArgumentResolver(@Login Member loginMember, Model model) {
if (loginMember == null) {
return "home"; //일반 홈화면으로
}
//@Login가 잘동작해서 Member객체를 잘 받아왔다면
model.addAttribute("member", loginMember); // 모델에 값을 담아준다 (뷰에서 데이터를 뿌려주기 위해)
return "loginHome"; // 로그인한 사용자 전용 홈화면을 렌더링
}
@Login 애노테이션이 있으면 직접 만든 ArgumentResolver 가 동작해서 자동으로 세션에 있는 로그인 회원을 찾아주고, 만약 세션에 없다면 null 을 반환하도록 개발해보자.
@Login 애노테이션 생성
@Target(ElementType.PARAMETER) //타겟은 파라미터 (어디에 이 어노테이션이 붙는지 설정)
@Retention(RetentionPolicy.RUNTIME) // 실제 동작까지 어노테이션이 남아있어야하므로 , 런타임까지 어노테이션 정보가 남아있는다.
public @interface Login {
}
내용은 비어있음.
@Target(ElementType.PARAMETER) : 파라미터에만 사용
@Retention(RetentionPolicy.RUNTIME) : 리플렉션 등을 활용할 수 있도록 런타임까지 애노테이션 정보가 남아있음
MVC1에서 학습한 HandlerMethodArgumentResolver 를 구현해보자.
LoginMemberArgumentResolver 생성
@Slf4j
public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {
// HandlerMethodArgumentResolver를 구현해줘야한다.
@Override
public boolean supportsParameter(MethodParameter parameter) {
log.info("supportsParameter 실행");
//MethodParameter parameter를 통해서 파라미터 정보가 들어온다.
//파라미터에 해당 어노테이션이 있는지 체크
boolean hasLoginAnnotation = parameter.hasParameterAnnotation(Login.class);
//파라미터가 Member 타입인지 체크한다.
boolean hasMemberType = Member.class.isAssignableFrom(parameter.getParameterType());
// isAssignableFrom 은 전달인자가 해당 클래스/인터페이스를 상속/구현했는지 체크한다.
// 즉 파라미터가 Member.class에 할당 가능한지 체크한다.
return hasLoginAnnotation && hasMemberType; //두가지를 다 만족해야 true , true면 resolveArgument()가 실행된다.
}
@Override
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
log.info("resolverArgument 실행");
HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest(); //HttpServletRequest를 가져온다.
HttpSession session = request.getSession(false); //꼭 false로해야한다. 안그러면 세션이 없을시 만들어지기 떄문
//세션이 없거나, 세션에 로그인정보가 없는 경우 ==> 로그인이 되어있지않을때
if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
return null;
}
//있다면 멤버 리턴 (오브젝트 그대로)
return session.getAttribute(SessionConst.LOGIN_MEMBER);
}
}
supportsParameter() : @Login 애노테이션이 있으면서 Member 타입이면 해당 ArgumentResolver 가 사용된다.
resolveArgument() : 컨트롤러 호출 직전에 호출 되어서 필요한 파라미터 정보를 생성해준다.
여기서는 세션에 있는 로그인 회원 정보인 member 객체를 찾아서 반환해준다.
이후 스프링MVC는 컨트롤러의 메서드를 호출하면서 여기에서 반환된 member 객체를 파라미터에 전달해준다.
WebMvcConfigurer에 설정 추가 (ArgumentResolver 등록)
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override //만든 ArgumentResolver를 등록해준다. WebMvcConfigurer안에있는 addArgumentResolvers를 오버라이드한다.
public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
resolvers.add(new LoginMemberArgumentResolver()); // ArgumentResolver 추가
}
결과 확인
http://localhost:8080/ 로 접속시 로그
홈으로 이동시
@GetMapping("/")
public String homeLoginV3ArgumentResolver(@Login Member loginMember, Model model) {
if (loginMember == null) {
return "home"; //일반 홈화면으로
}
//@Login가 잘동작해서 Member객체를 잘 받아왔다면
model.addAttribute("member", loginMember); // 모델에 값을 담아준다 (뷰에서 데이터를 뿌려주기 위해)
return "loginHome"; // 로그인한 사용자 전용 홈화면을 렌더링
}
해당 메소드가 실행되면서 @Login Member loginMember 에 대한 ArgumetResolver를 찾는과정에서
supportsParameter()가 실행되고 성공하면 resolverArgument()가 실행되면서 객체가 loginMember에 반환된다.
supportsParameter는 한번 실행되고나면 캐시에 저장되서 그 다음부터 홈으로 갈때는 로그가 안보인다.
정리
실행해보면, 결과는 동일하지만, 더 편리하게 로그인 회원 정보를 조회할 수 있다.
이렇게 ArgumentResolver 를 활용하면 공통 작업이 필요할 때 컨트롤러를 더욱 편리하게 사용할 수 있다.
ArgumentResolver를 이용해서 커스텀 어노테이션으로 홈 컨트롤러 메소드를 처리하기전
@GetMapping("/")
public String homeLoginV3Spring(
@SessionAttribute(name = SessionConst.LOGIN_MEMBER, required = false)Member loginMember, Model model) {
//@SessionAttribute로 한번에 세션에있는값을 가져올 수 있다.
// 쿠키에 있는 JSESSIONID를 가지고 세션을 검색하고, 그 세션안에 name에 넣는 키를 이용해서 값을 꺼내온다.
// 로그인하지않은 사용자(JSESSIONID를 가지고있지않은 사용자)도 이용할 수 있으므로 required = false로 해둔다.
if (loginMember == null) {
return "home"; //일반 홈화면으로
}
//세션에서 회원정보를 받아왔다면
model.addAttribute("member", loginMember); // 모델에 값을 담아준다 (뷰에서 데이터를 뿌려주기 위해)
return "loginHome"; // 로그인한 사용자 전용 홈화면을 렌더링
}
@SessionAttribute를 이용해서 로그인한 이용자라면 Member객체를 가져오고, 아니라면 null을 가지고오게 처리하고있다.
이런 @SessionAttribute를 사용하는 메소드가 많다면 @SessionAttribute부분이 너무 길어서 코드가 복잡해질것이다.
ArgumentResolver를 이용해서 커스텀 어노테이션으로 홈 컨트롤러 메소드를 처리한후
@GetMapping("/")
public String homeLoginV3ArgumentResolver(@Login Member loginMember, Model model) {
if (loginMember == null) {
return "home"; //일반 홈화면으로
}
//@Login가 잘동작해서 Member객체를 잘 받아왔다면
model.addAttribute("member", loginMember); // 모델에 값을 담아준다 (뷰에서 데이터를 뿌려주기 위해)
return "loginHome"; // 로그인한 사용자 전용 홈화면을 렌더링
}
@Login하나로 처리되므로 깔끔하다.
WebConfig 전체
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override //만든 ArgumentResolver를 등록해준다. WebMvcConfigurer안에있는 addArgumentResolvers를 오버라이드한다.
public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
resolvers.add(new LoginMemberArgumentResolver()); // ArgumentResolver 추가
}
// 인터셉터 등록은 클래스에 implements WebMvcConfigurer 추가해주고
// addInterceptors()를 오버라이드 해야한다.
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new Loginterceptor())
.order(1) //인터셉터 순서
.addPathPatterns("/**") //인터셉터를 적용할 패턴정보 , 서블릿 URL과 다르다!
.excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터가 제외되는 url
//서블릿 필터는 추가 필터를 등록하려면 스프링빈으로 또 만들어줘야하지만
//스프링 인턴셉터는 InterceptorRegistry에 새로운 인터셉터를 추가해주기만 하면된다.
registry.addInterceptor(new LoginCheckInterceptor())
.order(2)
.addPathPatterns("/**") // 모든 경로에 대해서 로그인체크를한다.
.excludePathPatterns("/", "/members/add", "/login", "/logout", "/css/**", "/*.ico",
"/error"); //해당 url은 인터셉터 적용 제외힌다.
}
// 직접 만든 필터를 등록해준다 자동 빈등록을 해주지않는 이유는 LogFilter 객체를 만들어서 스프링빈에 등록하려는게 아니고
// FilterRegistrationBean객체를 logFilter라는 스프링빈이름으로 등록하려고 하기 떄문인것같다.
// 스프링컨테이너에는 각 필터별 들이 스프링빈이름은 필터이름으로 가지고 , 스프링빈안에 빈객체는 FilterRegistrationBean를 가지며 그안에 필터객체,필터정보가 들어있는것이다.
// @Bean 로그처리 인터셉터도 있으니까 로그처리 필터는 주석처리.
public FilterRegistrationBean logFilter() {
FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>(); //필터 등록용 빈을 만든다.
filterRegistrationBean.setFilter(new LogFilter()); // 내가만든 필터를 넣어주고
filterRegistrationBean.setOrder(1); // 필터의 순서도 넣어준다.
filterRegistrationBean.addUrlPatterns("/*"); // 어떤 url패턴에 적용할것인지 설정, /*는 모든 url를 의미한다.
return filterRegistrationBean;
}
//로그인체크 필터 등록
// @Bean 필터는 안쓸거니까 주석처리
public FilterRegistrationBean loginCheckFilter() {
FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
filterRegistrationBean.setFilter(new LoginCheckFilter());
filterRegistrationBean.setOrder(2);
filterRegistrationBean.addUrlPatterns("/*"); //어차피 화이티리스트를 넣어놨기때문에 모든 url에 적용해도 알아서 걸러진다.
return filterRegistrationBean;
}
}
'인프런 > 스프링 MVC 2편' 카테고리의 다른 글
16) API 예외 처리 (0) | 2023.02.09 |
---|---|
15) 예외 처리와 오류 페이지 (0) | 2023.02.09 |
13) 로그인 처리2 - 필터 (0) | 2023.02.08 |
12) 로그인처리 - 쿠키, 세션 (실전) (0) | 2023.02.08 |
11) 로그인처리 - 쿠키, 세션 직접 개발,적용해보기(개념단계) (0) | 2023.02.06 |
댓글