일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 다대다
- 스프링 폼
- 백트래킹
- 비관적락
- fetch
- FetchType
- 즉시로딩
- 유니크제약조건
- 지연로딩
- 스토어드 프로시저
- 낙관적락
- 동적sql
- 이진탐색
- 일대다
- querydsl
- 힙
- JPQL
- 데코레이터
- dfs
- eager
- CHECK OPTION
- BOJ
- execute
- shared lock
- exclusive lock
- PS
- SQL프로그래밍
- 연결리스트
- 연관관계
- 다대일
- Today
- Total
흰 스타렉스에서 내가 내리지
서블릿 필터, 인터셉터 본문
# 공통 관심 사항
- 상품 관리 컨트롤러에서 로그인 여부를 체크하는 로직을 하나하나 작성하면, 등록/수정/식제/조회 등등 상품 관리의 모든 컨트롤러 로직에 공통으로 로그인 여부를 확인해야 한다. 이 때 발생하는 문제는, 로그인과 관련된 로직이 변경될 때이다. 작성한 모든 로직을 다 수정해야 할 수도 있다.
→ 실제로 내가 진행한 ㅌㅌ 프로젝트에서, 모든 API 경로에 대해서 가장 첫번째로 있는 코드는 헤더에 담긴 토큰으로 사용자를 불러오는 것이다. 이는 심각한 코드 중복이라고 생각한다.
- 애플리케이션 여러 로직에서 공통으로 관심이 있는 것을 공통 관심사(cross-cutting concern)라고 한다. 예를 들어, 여러 로직에서 공통으로 인증에 대해서 관심을 가지고 있다.
- 이러한 공통 관심사는 AOP 로도 해결할 수 있지만, 웹과 관련된 관심사는 지금부터 설명할 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다.
- 웹과 관련된 공통 관심사를 처리할 때는 HTTP의 헤더나 URL의 정보들이 필요한데, 서블릿 필터나 스프링 인터셉터는 HttpServletRequest 를 제공한다.
# 서블릿 필터
- 필터는 서블릿이 지원하는 수문장
* 필터 흐름
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러
- 필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다.
- 필터는 특정 URL 패턴에 적용할 수 있다. /* 라고 하면 모든 요청에 필터가 적용된다.
* 필터 제한
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 // 로그인 사용자
HTTP 요청 -> WAS -> 필터(적절하지 않은 요청이라 판단, 서블릿 호출 X) // 비 로그인 사용자
- 필터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝을 낼 수도 있다. 그래서 로그인 여부를 체크하기 딱 좋다.
* 필터 체인
HTTP 요청 -> WAS -> 필터1 -> 필터2 -> 필터3 -> 서블릿 -> 컨트롤러
- 필터는 체인으로 구성. 중간에 필터를 자유롭게 추가할 수 있다.
- 예를 들어, 로그 필터를 먼저 적용하고, 그 다음에 로그인 여부를 체크하는 필터를 만들 수 있다.
* 필터 인터페이스
public interface Filter {
public default void init(FilterConfig filterConfig) throws ServletException{}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException;
public default void destroy() {}
}
- 필터 인터페이스를 구현하고 등록하면, 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고 관리한다.
- init() : 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출된다.
- doFilter() : 고객의 요청이 올 때마다 해당 메서드가 호출된다. 필터의 로직을 구현하면 된다.
- destory() : 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출된다.
# 서블릿 필터 - 인증 체크
- 아래 예시 코드는 SSR에 스프링부트2.x.x 기준이니, CSR과 스프링부트3 버전에서는 다르다. 그냥 흐름만 이해하는 정도로 이해하고 넘어가자.
@Slf4j
public class LoginCheckFilter implements Filter {
private static final String[] whitelist = {"/", "/members/add", "/login", "/logout","/css/*"};
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
String requestURI = httpRequest.getRequestURI();
HttpServletResponse httpResponse = (HttpServletResponse) response;
try {
log.info("인증 체크 필터 시작 {}", requestURI);
if (isLoginCheckPath(requestURI)) {
log.info("인증 체크 로직 실행 {}", requestURI);
HttpSession session = httpRequest.getSession(false);
if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
log.info("미인증 사용자 요청 {}", requestURI);
//로그인으로 redirect
httpResponse.sendRedirect("/login?redirectURL=" + requestURI);
return; //여기가 중요, 미인증 사용자는 다음으로 진행하지 않고
}
}
chain.doFilter(request, response);
} catch (Exception e) {
throw e; //예외 로깅 가능 하지만, 톰캣까지 예외를 보내주어야 함
} finally {
log.info("인증 체크 필터 종료 {}", requestURI);
}
}
/* 화이트 리스트의 경우 인증 체크X */
private boolean isLoginCheckPath(String requestURI) {
return !PatternMatchUtils.simpleMatch(whitelist, requestURI);
}
}
whitelist = {"/", "/members/add", "/login", "/logout","/css/*"};
- 인증 필터를 적용해도 홈, 회원가입, 로그인화면, css 같은 리소스에는 접근할 수 있어야 한다.
- 이렇게 화이트리스트 경로는 인증과 무관하게 항상 허용한다.
- 화이트 리스트를 제외한 나머지 모든 경로에는 인증 체크로직을 적용한다.
# 스프링 인터셉터
- 스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다.
- 서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다.
- 둘 다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 그리고 사용방법이 다르다.
* 스프링 인터셉터의 흐름
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러
- 스프링 인터셉터는 디스패처 서블릿과 컨트롤러 사이에서 컨트롤러 호출 직전에 호출된다.
- 스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패처 서블릿 이후에 등장하게 된다. 스프링 MVC의 시작점이 디스패처 서블릿이라고 생각해보면 이해가 될 것이다.
- 스프링 인터셉터에도 URL 패턴을 적용할 수 있는데, 서블릿 URL 패턴과는 다르고 , 매우 정밀하게 설정할 수 있다.
* 스프링 인터셉터 제한
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 // 로그인 사용자
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출 x) // 비 로그인 사용자
* 스프링 인터셉터 체인
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 인터셉터1 -> 인터셉터2 -> 컨트롤러
- 스프링 인터셉터는 체인으로 구성되는데, 중간에 인터셉터를 자유롭게 추가할 수 있다.
- 지금까지는 서블릿 필터와 제공하는 기능은 비슷해 보이지만, 스프링 인터셉터는 서블릿 필터보다 편리하고 더 정교하고 다양한 기능을 지원한다.
* 스프링 인터셉터 인터페이스
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가 반환되는지 응답 정보도 받을 수 있다.
* 스프링 인터셉터 호출 흐름
* 예외 발생시
- 컨트롤러에서 예외가 발생하면 postHandle은 호출되지 않는다.
- afterCompletion은 항상 호출된다. 이 경우 예외를 파라미터로 받아서 어떤 예외가 발생했는지 로그로 출력할 수 있다.
- 예외가 발생하면 postHanle() 은 호출되지 않으므로 예외와 무관하게 공통 처리를 하려면 afterCompletion()을 사용해야 한다.
- 예외가 발생하면 afterCompletion() 에 예외 정보 (ex) 가 포함되어 호출된다.
* 인증체크 예시 코드
@Slf4j
public class LoginCheckInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String requestURI = request.getRequestURI();
log.info("인증 체크 인터셉터 실행 {}", requestURI);
HttpSession session = request.getSession(false);
if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
log.info("미인증 사용자 요청");
//로그인으로 redirect
response.sendRedirect("/login?redirectURL=" + requestURI);
return false;
}
return true;
}
}
- 서블릿 필터와 비교해서 코드가 간결하다.
'Spring' 카테고리의 다른 글
서블릿 예외 처리 - 필터, 인터셉터 (0) | 2023.12.29 |
---|---|
서블릿 (0) | 2023.12.28 |
쿠키와 세션, 그리고 서블릿 HTTP 세션 (1) | 2023.12.23 |
프로덕션 준비 - 액츄에이터 (actuator) (1) | 2023.12.17 |
각 환경마다 서로 다른 빈 등록 - @Profile (0) | 2023.12.16 |