22.09.09

Advance I/Spring MVC

22.09.09

kinggora 2022. 9. 9. 14:47

스프링 인터셉터 - 인증 체크

인증 체크 인터셉터

서블릿 필터와 비교해서 코드가 매우 간결하다.

인증이라는 것은 컨트롤러 호출 전에만 호출되면 된다. 따라서 preHandle 만 구현하면 된다.

인터셉터의 경우, default 메서드로 구성되어 있기 때문에 가능

미인증 사용자 요청의 경우, return false -> 로그인 페이지로 리다이렉트
인증 사용자의 경우 return true -> 다음 인터셉터, 컨트롤러 진행

인터셉터 등록

인터셉터를 적용하거나 하지 않을 부분은 addPathPatterns 와 excludePathPatterns 에 작성

기본적으로 모든 경로에 해당 인터셉터를 적용하되( /** ), //addPathPatterns

홈( / ), 회원가입( /members/add ), 로그인( /login ), 리소스 조회( /css/** ), 오류( /error )와 같은 부분은 로그인 체크 인터셉터를 적용하지 않는다. //excludePathPatterns

서블릿 필터와 비교해서 스프링 인터셉터가 개발자 입장에서 훨씬 편리하기 때문에, 특별한 문제가 없다면 인터셉터를 사용하는 것이 좋다.

ArgumentResolver 활용

(MVC 1편 / 6. 스프링 MVC - 기본 기능 요청 매핑 헨들러 어뎁터 구조)

@SessionAttribute(name=SessionConst.LOGIN_MEMBER, required = false) Member member

=> @Login Member member

컨트롤러에서 파라미터에 @Login 애노테이션이 있으면 직접 만든 ArgumentResolver 가 동작해서 자동으로 세션에 있는 로그인 회원을 찾아주고, 세션에 없다면 null 을 반환

@Login 애노테이션

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface Login {

}

@Target(ElementType.PARAMETER) : 파라미터에만 사용

@Retention(RetentionPolicy.RUNTIME) : 리플렉션 등을 활용할 수 있도록 런타임까지 애노테이션 정보가 남아있음

HandlerMethodArgumentResolver 구현체

@Slf4j
public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        log.info("supportsParameter 실행");

        //파라미터에 Login 애노테이션이 있는지 여부
        boolean hasLoginAnnotation = parameter.hasParameterAnnotation(Login.class);
        //파라미터 타입이 Member 또는 Member 의 자식인지 여부
        boolean hasMemberType = Member.class.isAssignableFrom(parameter.getParameterType());

        return hasLoginAnnotation && hasMemberType;
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, 
    		  NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        log.info("resolveArgument 실행");

        HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest();
        HttpSession session = request.getSession(false);
        if(session == null){
            return null;
        }
        return session.getAttribute(SessionConst.LOGIN_MEMBER);
    }
}

supportsParameter() : @Login 애노테이션이 있으면서 Member 타입이면 해당 ArgumentResolver 가 사용된다.
resolveArgument() : 컨트롤러 호출 직전에 호출 되어서 필요한 파라미터 정보를 생성해준다. 여기서는 세션에 있는 로그인 회원 정보인 member 객체를 찾아서 반환해준다. 이후 스프링MVC는 컨트롤러의 메서드를 호출하면서 여기에서 반환된 member 객체를 파라미터에 전달해준다.

ArgumentResolver 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(new LoginMemberArgumentResolver());
    }
    ...

8. 예외 처리와 오류 페이지

서블릿 예외 처리 - 시작

서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.

Exception (예외)
response.sendError(HTTP 상태 코드, 오류 메시지)

Exception(예외)

자바 직접 실행

자바의 메인 메서드를 직접 실행하는 경우 main 이라는 이름의 쓰레드가 실행된다.

실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다.

웹 애플리케이션

웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.

애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다.

그런데 만약에 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까?

WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)

> application.properties

server.error.whitelabel.enabled=false

WAS가 제공하는 예외 페이지를 확인하기 위해, 스프링 부트가 제공하는 기본 예외 페이지 off

response.sendError(HTTP 상태 코드, 오류 메시지)

오류가 발생했을 때 HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해도 된다. 이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

이 메서드를 사용하면 HTTP 상태 코드와 오류 메시지도 추가할 수 있다.

response.sendError(HTTP 상태 코드)

response.sendError(HTTP 상태 코드, 오류 메시지)

sendError 흐름

WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (response.sendError())

response.sendError() 를 호출하면 response 내부에는 오류가 발생했다는 상태를 저장해둔다.

그리고 서블릿 컨테이너(WAS)는 고객에게 응답 전에 response 에 sendError() 가 호출되었는지 확인한다.

그리고 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.

서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 사용자가 보기에 불편하다. 의미 있는 오류 화면을 제공해보자.

서블릿 예외 처리 - 오류 화면 제공

서블릿은 Exception (예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError() 가 호출 되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.

서블릿 오류 페이지 등록

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/400");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");

        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");
        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
    }
}

response.sendError(404) : errorPage404 호출

response.sendError(500) : errorPage500 호출

RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

오류 페이지는 예외를 다룰 때 해당 예외와 그 자식 타입의 오류를 함께 처리한다.

예를 들어서 위의 경우 RuntimeException 은 물론이고 RuntimeException 의 자식도 함께 처리한다.

오류가 발생했을 때 처리할 수 있는 컨트롤러가 필요하다.

ex. RuntimeException 예외 발생 -> errorPageEx 에서 지정한 오류 페이지 /error-page/500 요청 -> /error-page/500 컨트롤러

서블릿 예외 처리 - 오류 페이지 작동 원리

서블릿은 Exception (예외)가 발생해서 서블릿 밖으로 전달되거나 response.sendError() 가 호출 되었을 때, 설정된 오류 페이지를 찾는다.

1. WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.

new ErrorPage(RuntimeException.class, "/error-page/500")

2. 오류 페이지 정보가 존재하면, 오류 페이지를 출력하기 위해 지정된 path를 요청한다.

RuntimeException 예외가 WAS까지 전달되면 /error-page/500 를 다시 요청

오류 페이지 요청 흐름

WAS `/error-page/500` 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/ 500) -> View

오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

최종적으로 컨트롤러에서 오류 페이지가 렌더링 됨

서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.

오류 정보 추가

WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request 의 attribute 에 추가해서 넘겨준다.

필요하면 오류 페이지에서 이렇게 전달된 오류 정보를 사용할 수 있다.

request.attribute에 서버가 담아준 정보

javax.servlet.error.exception : 예외 (sendError는 null)

javax.servlet.error.exception_type : 예외 타입 (sendError는 null)

javax.servlet.error.message : 오류 메시지

javax.servlet.error.request_uri : 클라이언트 요청 URI

javax.servlet.error.servlet_name : 오류가 발생한 서블릿 이름

javax.servlet.error.status_code : HTTP 상태 코드

서블릿 예외 처리 - 필터

목표

예외 처리에 따른 필터와 인터셉터 그리고 서블릿이 제공하는 DispatchType 이해하기

서버 내부에서 오류 페이지를 호출한다고 해서 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다. 클라이언트로 부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다.

서블릿은 이런 문제를 해결하기 위해 DispatcherType 이라는 추가 정보를 제공한다.

DispatcherType

필터는 dispatcherTypes 라는 옵션을 제공한다.

고객 요청: dispatcherType=REQUEST

오류 페이지: dispatchType=ERROR

> javax.servlet.DispatcherType

public enum DispatcherType { 
    FORWARD, INCLUDE, REQUEST, ASYNC, ERROR 
}

REQUEST : 클라이언트 요청
ERROR : 오류 요청
FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때 RequestDispatcher.forward(request, response);
INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때 RequestDispatcher.include(request, response);
ASYNC : 서블릿 비동기 호출

필터와 DispatcherType

필터를 등록하기 위해 FilterRegistrationBean 을 생성할 때, DispatcherType 를 설정할 수 있다.

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

=> 클라이언트 요청( REQUEST ), 오류 페이지 요청( ERROR ) 모두 해당 필터가 호출

아무것도 넣지 않으면 기본 값이 DispatcherType.REQUEST

특별히 오류 페이지 경로도 필터를 적용할 것이 아니면, 기본 값을 그대로 사용

오류 페이지 요청 전용 필터를 적용하고 싶으면 DispatcherType.ERROR 만 지정